Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Airyx OS

airyx.org

Post reply on HN
Print view View original

241–250 of 258 posts

Re: Airyx OS

#241

Post by unicornfinder »

suction wrote: post #96
ericwooley wrote: post #60

Earlier quoted context omitted.

> this is against the terms of the Apple developer agreement. Of course it is Heaven forbid we have any choices at all.

To be fair, Macs are one of the best choices out there, so I'm not complaining. The only thing that sucks on Macs nowadays for devs is how poor Docker is performing, even with all the workarounds like Docker-sync etc.

A few years ago I would've agreed but WSL is so damn good now that I honestly prefer it over developing on a Mac, particularly as it solves a lot of the performance issues.

Re: Airyx OS

#242

Post by jscipione »

eafer wrote: post #88
fn1 wrote: post #75

Earlier quoted context omitted.

> how hard it is to implement a modern filesystem that won't eat users' data. Why is that so hard? Because of edge-cases? Caching/Timing considerations?

The main problem is simply that people really really really don't like losing their data after they saved it to disk. A simple app that corrupts its in-memory state once a year is probably acceptable. A filesystem that corrupts its on-disk state once a year is pure garbage. You basically need to aim for zero bugs. How hard this is, it depends on the filesystem. Something like FAT, for example, is pretty much designed…

And yet this didn't stop Apple from automatically converting HFS+ volumes to APFS in iOS 10.3 and macOS 10.13.0 soon after the APFS beta dropped in macOS 10.12.5 and it didn't stop Apple from requiring APFS for all volumes in macOS 10.14+. Apple must have been pretty confident that APFS was working reliably to be so bold.

Re: Airyx OS

#243

Post by chipotle_coyote »

Trufa wrote: post #101
gouggoug wrote: post #64

Earlier quoted context omitted.

You can have the desire to not eat meat, yet, love the taste, texture and sensation of it. These things aren't incompatible.

I know it's kind of offtopic, but having gone vegetarian around 2 years ago, it's amazing how many times I heard this argument presented in the way you SHOULD NOT want to replicate meat, you can't call that a burger if it doesn't have meat, I'm not one to get offended but I find it so weird. To this first one I have 2 points, 1. don't tell me what I want and don't want to do and 2. don't tell me what I want and don't…

I'm not a vegan -- or vegetarian -- but I've noticed that, too: I see lots of people complaining about pushy smug vegans always being pushy and smug at them, but see very few vegans being actively pushy and smug. One kind of suspects that it's simply letting people know that you're vegan that they're reacting negatively to. The smug pushy vegan is the one in their head.

Personally, I like a fair number of the "plant-based meats" that are out there. When I cook vegetarian I'm often interested in finding ways to get a satisfying taste without using a meat substitute, but that's because, well, I find it interesting. If I want a burger, I want a burger, and this whole "you can't name it after a thing that traditionally comes from animals if it doesn't come from an animal" nonsense is nonsense.

(And, as a long-time Mac user, I'm not sure it's entirely off-topic, as for many years I saw lots of people complaining about pushy smug Mac users always being pushy and smug at them, but saw very few Mac users actively being pushy and smug. It was pretty clear that just mentioning "oh, I use a Mac" was enough to set people off. The smug pushy Mac user was the one in their head.)

Re: Airyx OS

#244

Post by GekkePrutser »

jrsj wrote: post #188
GekkePrutser wrote: post #108

One thing I wonder is why they're using FreeBSD as a base and not Darwin. I use FreeBSD myself and it's great, but if you're really going for Mac compatibility I would use the same kernel considering it's FOSS.

Lack of device drivers mainly, I would assume. Could be something else, I know there were projects attempting to do things with Darwin in the past and none were successful.

Aha that explains a lot. Yes I'd imagine Darwin having drivers only for hardware used in Macs and nothing else. I didn't think of that.

Re: Airyx OS

#245

Post by nyanpasu64 »

forgotpwd16 wrote: post #133
orangeyjuicey wrote: post #113

Earlier quoted context omitted.

If any Hello devs are here, I just want to point out that I was interested in using their interface, until I noticed that the window titles are not centered based on the window but on the space between the window buttons and the window (this is on the website). That put me off the whole website (which is fast judgement on my part, but hey I've got stuff to do). Does anyone else here agree?

It is a known issue (ref: https://github.com/helloSystem/ISO/issues/145 ).

It's hilarious how a macOS-lookalike desktop environment is using Linux-like technologies like Openbox and KWin, rather than building something in Cocoa. I suspect it will cause trouble trying to bodge KWin to have Mac-like window management, or support apps that integrate with Apple's graphical acceleration and compositing frameworks (Core Animation? https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...).

Re: Airyx OS

#246

Post by eafer »

naasking wrote: post #240
eafer wrote: post #224

Earlier quoted context omitted.

> C being a shitty language that does not force or even encourage programmers to handle errors I don't see where this is coming from. Most of the world's top filesystems are written in C, and they work just fine. Maybe other languages could get better results, but it's hard to say with so little data. > implementation knowledge about file system technology is generally stuck in the 1990s If you are talking about me,…

I'm curious why you think file systems written in C would somehow be better than any other type of program written in C. We have plenty of data suggesting C programs have more bugs and vulnerabilities than programs written in safer languages.

If you are thinking about rust, we don't have any data about it in the context of the kernel yet, not even for device drivers. It may prevent some exploitable bugs, but those aren't a big concern for filesystems - otherwise they wouldn't be put inside the kernel at all. The reality is, we don't know if it would help; and given how conservative we all are with our filesystem implementations (for good reasons), it's possible that we never will.

Re: Airyx OS

#247

Post by eafer »

jscipione wrote: post #242
eafer wrote: post #88

Earlier quoted context omitted.

The main problem is simply that people really really really don't like losing their data after they saved it to disk. A simple app that corrupts its in-memory state once a year is probably acceptable. A filesystem that corrupts its on-disk state once a year is pure garbage. You basically need to aim for zero bugs. How hard this is, it depends on the filesystem. Something like FAT, for example, is pretty much designed…

And yet this didn't stop Apple from automatically converting HFS+ volumes to APFS in iOS 10.3 and macOS 10.13.0 soon after the APFS beta dropped in macOS 10.12.5 and it didn't stop Apple from requiring APFS for all volumes in macOS 10.14+. Apple must have been pretty confident that APFS was working reliably to be so bold.

Not sure why you are telling me this, I don't know anything about Apple's internal development process. I assume they did run a lot of tests. But I recall at least one serious bug early on too[0].

[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...

Re: Airyx OS

#248

Post by naikrovek »

greyhair wrote: post #229
eafer wrote: post #54

Earlier quoted context omitted.

> compatible with macOS filesystems (HFS+ and APFS) How far along is this? I think she's underestimating how hard it is to implement a modern filesystem that won't eat users' data. I've been working on a Linux APFS driver[0] for several years, and it's not fully functional yet. It's a pity that she is working with FreeBSD, or it could have been of use to her. [0] https://github.com/eafer/linux-apfs-rw

A lot of us have long been tired of the "all things must be Linux" mantra. It is nice having options, having other environments.

100% correct, and I think FreeBSD is woefully underrated.

Re: Airyx OS

#249

Post by naasking »

eafer wrote: post #246
naasking wrote: post #240

Earlier quoted context omitted.

I'm curious why you think file systems written in C would somehow be better than any other type of program written in C. We have plenty of data suggesting C programs have more bugs and vulnerabilities than programs written in safer languages.

If you are thinking about rust, we don't have any data about it in the context of the kernel yet, not even for device drivers. It may prevent some exploitable bugs, but those aren't a big concern for filesystems - otherwise they wouldn't be put inside the kernel at all. The reality is, we don't know if it would help; and given how conservative we all are with our filesystem implementations (for good reasons), it's po…

I'm not thinking about anything specific, I'm simply disputing your general claim that moving away from C would not help, when it has clearly helped in every single other domain of software development. I see no real reason why file systems should be any different, but clearly you do, so I was asking you why you think file systems would be different.

And for specific examples of options with better safety records, then sure Rust would be one possibility, as would Ada, or Frama-C if you need to stick with C.

Re: Airyx OS

#250

Post by protomyth »

pjmlp wrote: post #235
protomyth wrote: post #175

Earlier quoted context omitted.

If it is, then expect everyone selling PCs to get a nicely worded letter from IBM about their BIOS. Any jurisdiction that rules differently will imperil their whole software industry.

IBM already tried that in the 80's and lost, due to the way Compaq did it, that is why you have PC compatibles.

Yes, but Oracle's lawsuit was trying to rewrite the book so copying API was copyright infringement regardless of the clean room used.
Post reply on HN