[HN Gopher] Airyx OS
___________________________________________________________________
Airyx OS
Author : todsacerdoti
Score : 639 points
Date : 2021-08-05 01:11 UTC (21 hours ago)
(HTM) web link (airyx.org)
(TXT) w3m dump (airyx.org)
| shortformblog wrote:
| Airyx's developer may want to say hello to the developers of
| Hello, who are doing something very complementary to this with UX
| --and are quite far along already.
| https://hellosystem.github.io/docs/
| chaostheory wrote:
| I probably missed a lot of things, but didn't Gnome already
| achieve this? Weren't most of the people behind its design from
| Apple?
| shortformblog wrote:
| The developer of Hello would disagree with you:
| https://medium.com/@probonopd/hellosystem-three-layer-ux-
| des...
| chaostheory wrote:
| That's a good sign. Gnome has only become practical for me
| in recent years. I believe it's because its designers were
| from the original Mac OS era (pre OSX) where they favored
| too much simplicity at the cost of functionality. Maybe
| Hello designers are trying to get the balance of usability
| & functionality of OS X / modern Mac OS? If so, that's a
| great goal and I look forward to trying out what they have
| to offer in the near future.
| ivolimmen wrote:
| Funny how he complains about missing the German language
| setting and proposing a new system where my language
| (Dutch) is completely missing... I will stick to Gnome...
| shortformblog wrote:
| Clearly he designed an example from scratch to underline
| his basic point, which makes sense because he's making a
| point about user interface design. There are only a
| handful of languages in there--presumably an actual list
| will have more.
|
| What a silly reason to not use something.
| DanAtC wrote:
| Ubuntu's Unity was a lot more macOS-like with the default
| global menu bar, then they gave up on it :( Gnome doesn't
| even have a menu bar anymore, preferring apps use a single
| hamburger menu.
| orionblastar wrote:
| Unity was designed more for touchscreens, so that Ubuntu
| could make smartphones based on it. It didn't work out
| apparently.
| forgotpwd16 wrote:
| It was designed for touchscreens _and_ desktops; a so
| called convergent interface. For example HUD, which
| allowed you to search any menu option (ref:
| https://wiki.ubuntu.com/Unity/HUD#Overview), and its
| Dash, a desktop search utility, were clearly keyboard-
| oriented. The bigger icons that launcher and dash had
| were probably made that way for touchscreens.
| qwerty456127 wrote:
| Vanilla GNOME3 looks and feels a lot like it was designed
| for tablets as the primary target, keyboard users as the
| secondary and mouse users only as the third.
|
| Ubuntu Unity did not - it was great for classic desktop
| usage with Mac-like (most importantly, not a mediocre
| attempt to mimic but even better than the original in
| some aspects) UX + advanced supports for keyboard lovers
| + keeping the mobile in mind.
|
| IMHO late years Unity was the best Linux UI yet. If only
| they would add Pop_OS!-like tiling + some more little Mac
| goodies only experienced Mac users know it would be
| perfect. And I absolutely can not say the same about
| GNOME3 although I actually want a GNOME3 tablet.
| DanAtC wrote:
| Unity was originally designed for netbooks with limited
| screen real estate.
| foerbert wrote:
| Wow. I believe you, but I really don't want to.
|
| I always figured that whole branch of design came out of
| dealing with mobile limitations, with some amount of side
| benefit from more screen space to do useless but flashy
| things to make the boss/client happy.
|
| Why would you ever go that route for a general purpose
| desktop?
| AnIdiotOnTheNet wrote:
| Because modern UX designers consider users their enemy.
| It's the only explanation I've heard that fits all the
| data.
| jeremyjh wrote:
| It does sometimes seem like they are designing to impress
| other designers at talks and conferences, rather than to
| make users happy. But I respect anyone who develops open
| source end-user software. To say it is thankless is quite
| an understatement.
| trulyme wrote:
| Yes, it is, and I respect them too. I just wish UIs would
| be considered _finished_ once the major UX and
| implementation bugs were fixed. The reason I won 't touch
| eithet Gnome or KDE is that there have been so many
| reimplementations of their UI that I simply don't want to
| learn them again. And again. And again. Especially as
| they bring nothing new to the table, just more
| "flashiness".
| michaelmrose wrote:
| As someone who has used KDE 3, 4 5 I would say the only
| really big change was 3 -> 4 and many aspects of it have
| been refined/improved. I think if you plunked someone
| down who had only used KDE 4, released in 2008, in front
| of the current version in 2021 they would require minimal
| learning to catch up.
|
| Growth requires change and if you don't have a billion
| dollars up front you do this iteratively in small pieces
| by necessity.
| veidr wrote:
| Yeah I recently switched from macOS to a Gnome-using
| variant of Linux (Pop!_OS 21.04, which overall I really
| like and recommend if you are of the "I want to do my
| specific work and not tinker with my OS much" mindset like
| I am) and this design choice blew my mind.
|
| I'm OK with a global menu bar, or app-window menu bar, but
| hiding everything behind a stupid hamburger thing on a
| desktop computer?
|
| Weird choice IMO. I'm just living with it, though, since I
| don't really want to fuck around with my system itself.
| michaelmrose wrote:
| Gnome shares some of the same aesthetic choices and its co-
| founder famously went on the record as preferring Macs but
| I'm not aware of any substantial connection between Apple and
| Gnome. Gnome is strongly connected with Red Hat which
| naturally supports a lot of Linux development.
| s_dev wrote:
| How similar are Airyx and Hello to: https://www.darlinghq.org/
| orangeyjuicey wrote:
| 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?
| monkeycantype wrote:
| oh, why did you point that out to me!, now it's driving me
| crazy.
| forgotpwd16 wrote:
| It is a known issue (ref:
| https://github.com/helloSystem/ISO/issues/145).
| seltzered_ wrote:
| "0.2.2 is the first build of Airyx based on the helloSystem
| components and FuryBSD LiveCD installer. It can be run or
| installed from the ISO and should have better hardware support,
| in addition to the slick helloSystem desktop and applications."
|
| via https://github.com/mszoek/airyx/releases
| shortformblog wrote:
| Good eye. Probably should be made more clear in the readme,
| because it's the obvious question that came up for me.
| paxys wrote:
| I find it funny that there are people working (presumably)
| really hard to replicate the trademark OS X look and feel for
| other operating systems while Apple is working similarly hard
| to move away from it as quickly as possible.
| hulitu wrote:
| It's a general trend in SW development. If it works, fix
| it. It seems to make everyone except users happy.
| TchoBeer wrote:
| I had a buddy who had a sort-of designer-developer role
| who would say "if it ain't broke don't don't fix it"
| seltzered_ wrote:
| You have to think about it in terms of form-factor
| changes/evolution.
|
| There may be things users have grown to 'tolerate' that
| were accustomed to using only a desktop environment that
| may surprise those who might've managed possibly faster
| workflows on something like a tablet.
| superasn wrote:
| As a long time windows user, Linux Mint greatly eased my
| transition from Windows to Linux and now I love it so much that I
| am never going back to windows again.
|
| Such projects help reduce a lot of friction for people who want
| to switch but need a little help to make the jump.
| cercatrova wrote:
| Can I compile iOS apps on this? That's honestly the only thing
| holding me to macOS, I really wish Apple didn't force every iOS
| developer to use macOS to do so.
| DaiPlusPlus wrote:
| Isn't that dependent on your private key stored on Apple's
| equivalent to a TPM?
|
| That said, lots of IDEs let you build on Windows/Linux, they
| just use a daemon running on a headless Mac on your LAN (or a
| rented "cloud" Mac) to do the code-signing part.
| saagarjha wrote:
| No, building software for iOS is possible on other platforms
| although this is against the terms of the Apple developer
| agreement.
| ericwooley wrote:
| > this is against the terms of the Apple developer
| agreement.
|
| Of course it is
|
| Heaven forbid we have any choices at all.
| mvanbaak wrote:
| Nobody is forcing you to make ios apps
| moron4hire wrote:
| At my previous job, I got hired to build VR apps for the
| HTC Vive on Windows, which was exactly what I wanted to
| do. But I only ever got assignments to build AR apps for
| the iPad[0]. So while nobody was physically putting a gun
| to my head, there was the ever present threat of not
| being able to provide for my family.
|
| [0] And it didn't even make sense. I was making
| industrial equipment repair guide software. The first
| version of it I made for the Hololens, where it made
| sense, because, you know, you need your hands free to be
| able to actually enact the repairs. But you try telling
| that to a literally corrupt manager.
| suction wrote:
| 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.
| eropple wrote:
| They make references to a Darwin compat layer somewhere down
| the line.
| forgotpwd16 wrote:
| >It builds on the solid foundations of FreeBSD
|
| Why not build on Darwin which basically forms macOS's core?
|
| And how it differs from helloSystem?
| zekica wrote:
| > Why not build on Darwin which basically forms macOS's core?
|
| Possibly because of greater hardware compatibility.
| GNOMES wrote:
| Thought the same, but it does provide them a legal argument
| that it's not MacOS
| kaybe wrote:
| Hm, there is a German company with the same name..
|
| https://airyx.de/
| bastardoperator wrote:
| "compatibiilty with macOS(r) on x86-64 sytems"
|
| How does this materialize when MacOS is shifting away from
| x86-64?
|
| Also, they need to do some basic spell checking.
| PatrolX wrote:
| So you ripped off helloSystem, basically.
|
| https://github.com/helloSystem/hello
|
| Why?
| nsilvestri wrote:
| Having a similar idea is not the same as ripping off.
| PatrolX wrote:
| It's literally a copy of hello which makes it a ripoff.
|
| It also has the exact same stated goals, regarding macOS.
|
| So when the goal is the same my question is legit, why?
|
| What will be different to hello?
|
| Why not just contribute to hello?
| Drybones wrote:
| This looks super cool. Reminds me of GoboLinux a bit but with BSD
| and the goal of being an open Mac environment. This has my
| interest cause I'm looking into trying to do something similar
| but using Linux instead (mainly because of hardware and graphics
| support) but without the goal of being Mac compatible.
|
| I downloaded the preview ISO. I looks a lot like another BSD
| project I know that aimed to be an open BSD based Mac desktop.
| IDK if they renamed the project or if this is the same project I
| was thinking of.
|
| Screenshots from the Live CD: https://imgur.com/a/q3hp0np
| Drybones wrote:
| Hello is the BSD Desktop project I was thinking of, someone
| mentioned it in a reply in this thread [0]. Also a very cool
| project.
|
| 0: https://news.ycombinator.com/item?id=28068864
| shortformblog wrote:
| Agreed; and to be clear, it's great if both evolve
| separately. Building MacOS analogues is a great goal for BSD-
| based projects, especially given all the old machines that
| could use them, and I think will attract new folks to that
| community.
| grappler wrote:
| curious how Airyx devs think about the question of supporting
| apple silicon arm64, like m1 (or presumably m2 etc later on). Is
| it an explicit non-goal? A question of having the resources?
| kamilszybalski wrote:
| Why do you think people want this?
| sehro wrote:
| The people making this want this. Why do you assume everything
| that someone makes must have a market to be worth making?
| dotBen wrote:
| People with old computers that no longer receive MacOS security
| updates, but are still perfectly functional and pretty powerful
| computers.
| hellbannedguy wrote:
| That is a big market, I believe.
|
| I don't think I will ever buy a new Mac. I will by used
| though.
|
| I will continue buying Phones, and Ipads, until there's a
| comparable product.
| pjmlp wrote:
| Given the amount of stuff GNUStep is lagging behind macOS
| Frameworks after three decades, let alone the Swift ones, what is
| this for?
| kottaram wrote:
| Why cant you guys add some screenshots?
| KronisLV wrote:
| Seconding this! Having some screenshots on the homepage would
| be very useful, since most other OS distros out there offer
| that.
|
| Some other users in this thread did link some Imgur galleries
| of the live CD, though: -
| https://imgur.com/a/OsxT3GI ( from
| https://news.ycombinator.com/item?id=28070125 ) -
| https://imgur.com/a/q3hp0np ( from
| https://news.ycombinator.com/item?id=28068895 )
| michaelmrose wrote:
| This reminds me tangentially of another formerly BSD project
| trident formerly based on TrueOS that made the jump to being
| based off void Linux.
|
| Given the differences in hardware support between Linux and
| FreeBSD, the fact that FreeBSD is slightly more similar under the
| hood provides next to no benefit when you already need a layer
| like wine anyway, and especially the necessity to produce an APFS
| filesystem if this wont end up going the same route ultimately.
| zinclozenge wrote:
| Is it going to use the same keybinding convention that macOS
| uses, ie cmd-c/v for copy/paste etc?
| burlesona wrote:
| Sorry for what I'm sure is a stupid question, but what base this
| on BSD rather than Darwin itself?
|
| Or, probably a better question, how am I misunderstanding the
| situation :)
| sedatk wrote:
| Perhaps because APSL is incompatible with GPL?
| tpoacher wrote:
| Presumably Apple is waiting for this project to invest a huge
| amount of time and resources and be almost ready to release
| before suing the hell out of them, in order to discourage similar
| efforts?
| rimliu wrote:
| Of course, it is the sole purpose of Apple existence.
|
| How do you people even come to these conclusions?
| fstrthnscnd wrote:
| I understand it was meant as a rhetorical question, but I
| think there's a plausible response to that.
|
| People looked at the behaviour of many large companies when
| they had to deal with IP infringement, and the most memorable
| examples were when they waited until near completion before
| launching a legal procedure (I've seen that mostly from the
| movie industry). From this behaviour, they then try to guess
| an ulterior motive.
|
| The issue is that they fail to notice that a procedure on IP
| infringement is more likely to succeed when the supposed
| infringing work is closer to its source of inspiration: suing
| too early is a recipe of failure.
|
| It's clear that phrased as it was, it painted Apple as an
| intrinsically bad actor. And you reacted to that. It is
| probably closer to the truth that it is in Apple's interest
| to protect its market using all available legal means. If
| this project turns out to be a threat, I don't think it is
| unreasonable to expect their legal team to make a move. But I
| don't think either that they are naive enough to believe that
| a success would dissuade the rest of the world from trying
| again.
| skee_0x4459 wrote:
| people are hungry for a new utilitarian but fresh desktop OS.
| after the phone-home thing macos doesnt even exist as an option
| in my mind. i really like elementaryOS.
| shapefrog wrote:
| This reminds me of vegan bacon.
|
| If you dont want to eat meat, why try and replicate the taste,
| texture and sensation of eating meat?
|
| If you dont want to use macOS, why try and replicate the taste,
| texture and sensation of using macOS?
| Accacin wrote:
| I am not vegan because I do not like meat, I am vegan because I
| think that it bad for the environment and causes unnecessary
| suffering to animals.
|
| The fact that I could enjoy meat without any of those downsides
| is appealing to me :)
| rimliu wrote:
| Change your thinking and you will be able to enjoy it again.
| 1_player wrote:
| Did you really have to sidetrack and bait a technical
| conversation by mentioning vegan bacon?
|
| Enjoy the off topic comment chain.
| endofreach wrote:
| If you don't want to rape people, why try and have sex at all?
|
| And even more absurd to use this kind of argument in the
| software world. Imagine back then... ,,If you don't like Unix,
| why...", or the first GUI implementations on Linux trying to
| achieve what apple or microsoft did... Oh well, what our hacker
| world would be like if more people thought that way...
|
| Sorry, not trying to offend, but these projects are what I live
| for. ,,Stickin' it to the big guys" - after all, we are
| hackers, aren't we?
| wraptile wrote:
| because Macbooks aren't great machines:
|
| - expensive.
|
| - unergonomic.
|
| - locked in.
|
| I need macbook for work but I use Linux personally. Would be
| great if I could have native toolset on both.
|
| Also there are hundreds of perfectly valid reasons to not want
| to support or deal with Apple.
| animal_spirits wrote:
| macOS comes with the cost of an expensive computer, this is a
| free OS that mimics a well designed one.
| AnIdiotOnTheNet wrote:
| > If you dont want to eat meat, why try and replicate the
| taste, texture and sensation of eating meat?
|
| Because the taste and texture of meat are pretty great, it's
| just that whole "raising and killing a sentient being" thing
| that's the problem.
|
| The argument for something like Airyx is pretty similar: there
| are things to like about MacOS and things to not like about it,
| and it'd be great to get an alternative that has fewer
| negatives.
| gouggoug wrote:
| You can have the desire to not eat meat, yet, love the taste,
| texture and sensation of it. These things aren't incompatible.
| Trufa wrote:
| 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 want to do. For the second point, when did you
| become a burger defender.
|
| Before being vegetarian I've always heard how annoying are
| vegans trying to convince you bla bla bla, while I know it's
| circumstantial, I've almost never had that experience, but
| when I stopped eating meat, I've had dozens of people tell me
| I'm wrong, doing harm, it's stupid, pointless and that I
| should reconsider my personal dietary choices.
| theonemind wrote:
| The obvious answer, of course, is that you do want to eat meat
| and run macOS for some reasons, but don't want to for other
| reasons, so I'm not sure what you really mean. Should we forget
| the good parts of things with bad aspects and not chase
| facsimiles, or embrace the bad aspects of things with good
| parts..? Neither one really makes sense to me; fake meat and
| fake macOS make sense to me, though I eat meat and use macOS.
| Or perhaps just that we should find substitutes that don't
| attempt mimicry.
| fny wrote:
| Simple. Meat is delicious, but for some it comes with ethical
| issues. If you they replicate the taste (or sufficiently delude
| yourself), they can enjoy "meat" once again and sleep at night.
| mike_hock wrote:
| Or like Lesbians using a strap-on ...
| klemcijada wrote:
| You want the taste you are used to but don't want to increase
| demand for animal abuse.
| factorialboy wrote:
| Here is a reason: Mac OS telemetry is just as bad as Windows.
| Few months ago app launches on Mac OS slowed down because the
| service that received the "app launch event" degraded.
| /Facepalm
|
| It's awful how very few in the tech community challenge Apple
| for their false privacy claims.
|
| /Happy and productive onna Linux desktop
| bayesian_horse wrote:
| I agree. It doesn't make particular sense. Even if you aren't a
| complete fanatic about MacOs UI, you wouldn't choose FreeBSD as
| a base, but rather Linux, which has a lot of advantages for the
| average user, I'd say.
| garciasn wrote:
| Let's not forget that projects like this are cool and we
| should support developers who are biting off a ton.
| trasz wrote:
| Can you give some examples for those advantages?
|
| Also, note they because FreeBSD is orders of magnitude less
| bloated and organizationally convoluted, it's easier to
| implement functionality you need.
| fredsir wrote:
| > This reminds me of vegan bacon.
|
| > If you dont want to eat meat, why try and replicate the
| taste, texture and sensation of eating meat?
|
| What is this taste, texture, and sensation of meat in regards
| to bacon you're talking about? Bacon is the opposite of the
| actual taste, texture, and sensation of meat. It's cooked,
| salted, and processed to give it that taste, texture, and
| sensation.
|
| It's the same with people making fun of plant-based burgers and
| sausages. Well, guess what, burgers and sausages don't exist in
| nature, neither as meat nor plant. Well, actually... Cucumbers
| and a few other plants seem quite like sausages. Anyways. The
| burger, sausage, and bacon form factor is what makes it
| attractive. It's why people have liked it for so long, and why
| people like it still when they switch to a plant-based diet.
|
| I guess it's the same reason why some people are into Airyx OS.
| fithisux wrote:
| I thought it was a more polished version of PureDarewin.
| lloydatkinson wrote:
| > Drag and drop app install and uninstall - no package manager,
| no installers
|
| Awful
| etaioinshrdlu wrote:
| I think macOS has too large of an API nowadays to try to copy.
| There are a whole smorgasbord of frameworks. This can only really
| help with the simplest of Cocoa applications.
|
| This might be OK though, because I think what a hacker interested
| in this is really interested is the parts of macOS that are
| common with NextSTEP. Which are all the parts 20+ years old!
| tgv wrote:
| I checked a few files, and a lot of the foundation library have
| 2007 until 2009 copyright notices. Another random check,
| CALayer.h and CATransform3D from the Quartz framework, shows
| terribly limited functionality in comparison to the files on
| macOS 11.5. The latter comes with 198 frameworks, Airyx has 16,
| 2 of which don't exist (anymore). Catching up seems an
| impossible task.
| pjmlp wrote:
| Just look at GNUStep for a failed effort to keep up, despite
| it existing since the golden days of AfterStep and
| WindowMaker.
|
| Does GNUStep even support latest Objective-C runtime?
| GekkePrutser wrote:
| 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.
| jrsj wrote:
| 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.
| lowalden wrote:
| Does anyone have a screenshot of the OS? I can't see it on their
| Twitter page. I am quite curious about how beautiful the OS
| looks.
| rijoja wrote:
| User sdrinf added a link to screenshots in this thread.
| qwerty456127 wrote:
| No screenshots for a GUI-centric OS? Seriously?
| StevePerkins wrote:
| The OS doesn't exist today. Mostly likely it never will. Like
| half of the projects posted to HN, this is "aspirational". A
| landing page for a project that someone would sure like to do.
| slaughtr wrote:
| Sure it does, they link to the developer preview:
| https://github.com/mszoek/airyx/releases
| StevePerkins wrote:
| That is essentially a repackaging of helloSystem
| (https://hellosystem.github.io/docs), which itself is a
| FreeBSD spin with a custom display manager.
|
| The "source code" in this repo consists entirely of
| Makefiles and build scripts for working with helloSystem,
| along with a few FreeBSD header includes that were copied
| verbatim.
|
| I mean, more power and best of luck to the author here. But
| let's not exaggerate the act of forking another repo and
| tinkering with its build process. All of the items in the
| post here (e.g. macOS application and filesystem
| compatibility) are still twinkles in the author's eye at
| this point.
| ABS wrote:
| oh c'mon, it's a pre-alpha/pre-release of something someone is
| developing in their spare time and haven't even posted on HN
| themselves.
|
| It's open and on github. It clearly says at the bottom of that
| page A Developer Preview image of Airyx is
| currently available here. It's open to everyone, but is mainly
| intended for developers helping build the system and is not
| ready for daily use yet. Running in a virtual machine is
| recommended, although it should work on any hardware supported
| by FreeBSD 12.2 with at least 4GB RAM. (8GB is recommended.)
|
| and there is a direct link to the download page.
|
| Downloading the ISO and mounting it in a VM took me problably
| less time than it took you to write this self-entitled comment.
| throwaddzuzxd wrote:
| Come on, you can't seriously respond to "can I see some
| screenshots" with "just download the ISO and install a VM"...
|
| Requesting screenshots is not entitlement, it's both
| legitimate AND a useful advice to improve the landing page.
| throwaddzuzxd wrote:
| This is incredibly common. Why would you develop anything and
| then not provide screenshots? Even for CLIs screenshots are
| useful!
|
| What's the first thing you see on Apple's Big Sur landing
| page[1]? A big fat screenshot!
|
| What about Windows 11 preview[2]? Yep, screenshots!
|
| I can't think of a single time when the first thing I want to
| see on a landing page (or 1 click away) is not a screenshot or
| a demo.
|
| [1]: https://www.apple.com/macos/big-sur/ [2]:
| https://www.microsoft.com/fr-fr/windows/windows-11
| suction wrote:
| I wonder if the reason is that it looks really unpolished
| (there are some screenshots on Imgur). Those sidebars would get
| your team fired at Apple.
|
| If this isn't the final look then I apologise.
| cestith wrote:
| It's not the final anything. It's a pre-alpha developer's
| preview.
| maxpert wrote:
| We need a review video please!
| vzaliva wrote:
| Projects like these will be always one step behind the thing they
| are trying to replicate (MacOS in this case). It is better to
| spend one's creative energy innovating and coming up with
| _better_ solutions rather than re-implementing what Apple is
| doing.
| peatmoss wrote:
| I disagree. NeXT / macOS has been a pretty stable target for a
| very, very long time. If you're going to clean room implement
| anything, a stable thing is a great target.
|
| macOS has, however, been making superficial changes that people
| don't care about. A free macOS desktop alternative would build
| on a stable set of core technologies, and let people do the
| crazy things that they want, and not do the crazy things that
| they don't want.
| endofreach wrote:
| The ,,good thing" is, that Apple seems to be heading in wrong
| directions. So yes, it will be behind. Until suddenly it
| stops following and have it's own direction. It is way
| overdue for a change in the ecosystem again. There should be
| more choices for the average user. I urge everyone who has
| some demanded skills to get involved in projects like this.
| It is time.
| martian42 wrote:
| What wrong directions you're referring to?
| scns wrote:
| Design uber alles? Form over function? Butterfly
| keyboard? Jobs may not be in my list of favourite people
| but i think he had a good sense what works.
| wmf wrote:
| _It is better to spend one 's creative energy innovating and
| coming up with better solutions rather than re-implementing
| what Apple is doing._
|
| What if you spend your entire career innovating and the result
| is still worse than Snow Leopard?
|
| (/me kicks GNOME into a bottomless pit)
| fsflover wrote:
| > Projects like these will be always one step behind the thing
| they are trying to replicate (MacOS in this case).
|
| No, they won't. MacOS and Windows are both going backwards in
| innovations (according to many HN commenters at least). At some
| point this project (and ReactOS) will get better than the
| originals.
| zepto wrote:
| > It is better to spend one's creative energy innovating and
| coming up with better solutions rather than re-implementing
| what Apple is doing.
|
| I'd argue that there is room for both.
|
| But, who is attempting anything better?
| Wowfunhappy wrote:
| Luckily, macOS was at its best ~8 years ago, so it's okay if
| they're behind.
| shortformblog wrote:
| Given that there's 20 years of "behind," and many of those
| machines are no longer getting updates, what's the harm? The
| dev learns something and the community gains knowledge from the
| project.
|
| I was once critical of ReactOS for similar reasons, but I've
| realized just how beneficial that project has been to OSS as a
| whole. Even if they fail they will uncover a lot of interesting
| stuff if the project continues long-term.
| DaiPlusPlus wrote:
| I'd argue that Wine has been of far greater utility than
| ReactOS - both to users and as contribution to open-source.
| jagger27 wrote:
| There is a ton of cross-pollination between the ReactOS and
| Wine projects. Sure, Wine is more useful but they wouldn't
| exist as they do today without each other.
| aeoleonn wrote:
| Eh, I don't see much difference between older MacOS versions
| such as Mountain Lion compared to Big Sur.
|
| Similarly, I don't see much difference between Ubuntu desktop
| distros in terms of differences across versions , say from 16
| to 20.
|
| Therefore... I don't see a being "one step behind" as any kind
| of issue. I've never run into an issue with past versions (such
| as those menntioned above) of OSes not running what I need them
| to run.
|
| Personally, I'd like to see a Linux version which is very close
| to Apple so I can use it (such as OP's), instead of expensive
| Apple computers.
| HomeDeLaPot wrote:
| It could be argued that just by being community-driven and open
| source, projects like these are in fact better. It all depends
| what "better" means to you. (E.g. not phoning home to Apple
| every time you open a program...)
| suction wrote:
| Not to diminish the effort, but I think replicating the look and
| design (as in how things work) of MacOS (or Windows 10) is a
| pitfall that very few alternative OS developers manage to avoid.
|
| It's just a bad idea. They'll never get even close, and those
| screenshots on Imgur prove it.
|
| What I'd prefer is if these definitely brilliant developers would
| "own" the Unix history more, and build upon Motif. Put the effort
| do create a mimicry of MacOS into modernising Motif. Hopefully
| not just make the chrome translucent, but really think about how
| Motif would look if invented in 2021.
| otabdeveloper4 wrote:
| Gnome is good enough.
| zokula wrote:
| Gnome was good enough until the Gnome 3, by then it lost the
| plot.
| chakkepolja wrote:
| This but unironically for KDE. (UI wise)
| dmitriid wrote:
| > It's just a bad idea. They'll never get even close, and those
| screenshots on Imgur prove it.
|
| It's a great idea. Because developing your own look and feel
| for the entire OS is an enormous task. This way you at least
| have a foundation to build upon.
| neilalexander wrote:
| It's also an enormous task to replicate one. User interface
| design isn't just about rounded edges and aqua chrome, it's
| about all of the small details: spacing, scale, padding,
| margins, font rendering and hinting, colour, arrangement,
| target zones, interactive feedback, discoverability.
|
| While I am delighted that there are people out there trying
| to build open source desktops that are more friendly and
| attractive, it isn't going to turn out well unless you have
| people on board who really know and grok user interface
| experience and design. For a good example of this, look at
| the vast quality difference between helloSystem and
| elementaryOS -- the latter having significantly more
| attention poured into the smaller design details and it is
| immediately obvious how much of a difference that makes.
|
| You can't just duplicate what you think you see. You have to
| also understand why it was designed that way in the first
| place.
| hda111 wrote:
| hello started out of dissatisfaction with elementaryOS.
| hello tries to replicate Mac OS not how it looks but how it
| works. It's not fair to compare elementary to such a new
| project maintained by one person.
| neilalexander wrote:
| There's a big difference between replicating how
| something looks or works and replicating how something
| actually feels to use. Granted, elementaryOS is a more
| mature project with more people behind it but the
| attention to all those little details is what makes it
| feel nice to a user.
|
| My point is that helloSystem and/or Airyx are going to
| need that same level of design attention if it's ever
| going to feel like an adequate substitute. That tends to
| be where most open source desktops miss the mark today --
| they feel like they were designed by developers, not
| people who understand what makes up a good user
| interface.
| dmitriid wrote:
| > You can't just duplicate what you think you see. You have
| to also understand why it was designed that way in the
| first place.
|
| Of course, that should be the main driving force: to
| understand the why and the how.
|
| All I'm saying is that it's easier to do by copying an
| existing design than trying to come up with your own. Fake
| it till you make it is also a part of the process :D
| suction wrote:
| As I'm saying, to choose MacOS or Windows 10 as your
| foundation is a dead-end. Many have tried before.
|
| If you read my comment, you'd have read that I propose to
| look to the history of Unix as the foundation.
| dmitriid wrote:
| Why is it a dead-end and building on the outdated Motif
| isn't?
| speedgoose wrote:
| It looks like a counterfeit operating system though.
| mhd wrote:
| That's an interesting take. It would've been interesting if
| Motif were open sourced a few years earlier, as there would've
| been fewer wars about the correct Linux X11 toolkit (amongst
| the commercial Unices, this was just settled with Motif/CDE
| being the winner).
|
| The first Gimp version even was written in Motif, before its
| developers started Gtk (and bikeshedding Xt)...
|
| (I wouldn't start with a 2021 vision, as that seems to imply
| bad versions of over-stylized web and app interfaces, being
| almost as bad as the worst of the skeuomorphic UIs)
|
| So, looking at CDE, what was specifically "Motif" about it? I
| don't think the file management was as special and intrinsic as
| the spatial Finder, Win95s tree+file view explorer or even
| NextStep's Miller columns.
|
| Prominent virtual desktop usage?
|
| More "active" use of color?
|
| I think the dtksh part could be something interesting. Bridging
| the gap between regular Unix shell scripting (still more common
| than VBS or Rexx usage on other platforms) and UI creation.
|
| Now, I don't think this is the way of the future, but it's not
| like anything will come out of the Mac clones (Etoile, hello,
| Airyx) either, and this seems like a more original thought
| experiment.
| muterad_murilax wrote:
| And while they are at it, they really oughta think about how
| that Unixy 3D file manager from Jurassic Park would look if
| invented in 2021!
| rwmj wrote:
| You want developers to start with the clunky design, poor
| usability and terrible implementation of Motif?
| suction wrote:
| Yep.
| azinman2 wrote:
| It's hard to tell how far they're at. No screenshots? No progress
| bar?
| AnIdiotOnTheNet wrote:
| I'm not really sure why this project exists separately from
| Hello, and loath the idea that something like that is already
| fragmenting, Linux distro style. That said, having more things
| out there demonstrating that application management need not be
| any more complex than file management is good. It seems like
| people who never experienced AppDirs, Application Bundles, or the
| original Mac Applications simply can't conceive of a universe in
| which applications don't need an installer or a specialized
| complicated management tool.
| chaosharmonic wrote:
| This is kind of an aside, but can mods edit links the way they
| can post titles?
|
| This is routing to a plain HTTP URL for some reason despite a
| valid HTTPS one existing.
| [deleted]
| cable2600 wrote:
| What is the difference between this and GNUSTEP
| http://www.gnustep.org/ and Darling http://darlinghq.org
| gizdan wrote:
| Not sure about GNUstep, but Darling is akin to Wine, in that it
| is a re-implementation of the Mac APIs within a Linux
| environment, allowing you to run MacOS apps on Linux without
| recompilation. Whereas Airyx is a full FreeBSD OS
| (distribution?) that tries to mimic MacOS as a whole.
| andrewmcwatters wrote:
| Cool! Screenshots?
| oceankid wrote:
| I'd love to throw an investment into something like this with
| GUI, marketing and supply chain resources to build a solid
| computer under $300 for a developing world.
|
| Go up against Fuchia and Google hardware in less time and with
| more clarity.
| amelius wrote:
| I think this could be more successful if they break it into
| parts. E.g. a window manager, and separate macOS emulator. And
| allow other BSD/Linux/Unix distributions to use them as well and
| install them as packages.
| 3np wrote:
| More information and motivation in the git repo[0], the link to
| which I didn't spot easily in the site header.
|
| The main design goals are:
|
| * source compatibility with macOS applications (i.e. you could
| compile a Mac application on Airyx and run it)
|
| * similar GUI metaphors and familiar UX (file manager,
| application launcher, top menu bar that reflects the open
| application, etc)
|
| * compatible with macOS filesystems (HFS+ and APFS) and folder
| layouts (/Library, /System, /Users, /Volumes, etc)
|
| * self-contained applications in folders or a single file and a
| (mostly) installer-less experience for /Applications
|
| * mostly maintain compatibility with the FreeBSD base system and
| X11 - a standard Unix environment under the hood
|
| * compatible with Linux binaries via FreeBSD's Linux support
|
| * eventual compatibility with x86-64 macOS binaries (Mach-O) and
| libraries
|
| * pleasant to use, secure, stable, and performant
|
| [0] https://github.com/mszoek/airyx
| eafer wrote:
| > 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
| fn1 wrote:
| > 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?
| bmn__ wrote:
| The big problems continue to be
|
| * C being a shitty language that does not force or even
| encourage programmers to handle errors
|
| * implementation knowledge about file system technology is
| generally stuck in the 1990s
|
| * disk controller hardware lying to the OS to make them
| appear more performant than they really are
|
| visit https://danluu.com & ctrl+f "files"
| eafer wrote:
| > 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, that might be true, I'm
| relatively new to this and still learning. But there's
| definitely people out there with some serious
| "implementation knowledge". And tools like xfstests did
| not exist in the 1990s, that makes a huge difference.
| queuebert wrote:
| Can you elaborate on the second point?
| bmn__ wrote:
| courses offered by polytechnics and online learning
| platforms not being up-to-date, restricted and uneven
| access to expert implementers
| eafer wrote:
| 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 for ease of
| implementation, with few edge cases. Modern filesystems are
| not like that at all, the data structures are very
| complicated, so they must be extremely well tested before
| they are good enough to use. That would probably require an
| fsck to check for subtle inconsistencies; in the case of
| APFS you can use mine, but it's still very incomplete.
| Apple's published fsck is not very thorough.
|
| As an example of the kind of problems to expect, I recall a
| bug in the Linux HFS+ driver. If you had a drive with lots
| of short filenames and lots of long filenames, and you
| started deleting the short filenames, eventually you would
| lose half of your files. This kind of things happen because
| HFS+ has variable-length keys in the index nodes of its
| trees, so deleting a record may trigger a complicated
| cascade of node splits. APFS inherited this feature, and it
| was very annoying to implement.
|
| But HFS+ is very well documented; APFS is not, and that
| doesn't help.
| hnlmorg wrote:
| It's worse than this. You not just need to aim for zero
| bugs, but zero bugs despite working with hardware that
| can degrade with use and who's firmware often _does_ have
| bugs.
| trasz wrote:
| HFS+ is open source, so you don't even need to rewrite it
| from scratch.
| greyhair wrote:
| A lot of us have long been tired of the "all things must be
| Linux" mantra. It is nice having options, having other
| environments.
| pwrplus1 wrote:
| > It's a pity you are working with Linux, or it could have
| been of use to her.
|
| FTFY
| eafer wrote:
| Oh, I wasn't trying to diss FreeBSD. It would probably have
| been better to write my driver for fuse to make it
| portable, but it's too far along at this point.
| atombender wrote:
| Out of interest, why can't file system implementations be
| portable? A shared core that exists as a library that can
| be tested in userland, and which can then be used by a
| lightweight shim that implements the kernel-facing
| interfaces. But I haven't seen any file systems
| implemented this way.
| eafer wrote:
| Shims in the kernel seem a bit anti-social, since all
| module developers are expected to contribute to the
| shared core code. Of course it can be done, and it has
| been done. But I think FUSE is better if all you care
| about is portability, and you don't mind the heavy
| performance cost. My module could be ported for FUSE of
| course, but it's a lot more work than it may seem, the
| kernel interfaces are too alien compared to a userland
| library.
| Conan_Kudo wrote:
| The irony is that most of the newer ones in Linux _are_
| written that way, just nobody writes a FUSE binding to
| them. For example, both Btrfs and XFS contain fully
| functional pure-userspace implementations of the
| filesystem inside their userspace code (libbtrfs and
| libxfs both contain the complete filesystem code), but
| nobody has written a FUSE binding to either.
|
| Btrfs' implementation is even used to do most of the
| functionality in the tools (like send/receive) rather
| than using the kernel to do it (in order to minimize
| context switches that reduce I/O performance).
| codetrotter wrote:
| FUSE is neat for one-off access to obscure file systems,
| and FUSE is usable for things like sshfs for those who
| use that, but it is my impression from having used FUSE
| myself that FUSE does come with a noticeable performance
| penalty. Is my perception wrong on this? Because if it is
| not then I'd be hesitant to use a system where the main
| storage was relying on FUSE.
| aidenn0 wrote:
| FUSE is also great for slower media. Copying files over
| USB sticks without being restrained by FAT-32 limitations
| is great. There have been times that I've used NTFS-3g
| for this because its FUSE implementation meant I could
| read it on any OS.
| lapinot wrote:
| Stuff like gocryptfs seem to push FUSE to quite high
| performance. There is still some latency but streaming
| read/write seem to go fast.
| geocar wrote:
| Do you have any documentation on that?
|
| The benchmarks on their website[1] compare it running on
| a 4 x 3.20GHz with hardware AES-N instructions, against
| an in-kernel implementation of a different cryptosystem
| running on a 2.7GHz cpu that does NOT have AES
| instructions. I also can't see anything that speaks to
| speed of the storage (or if this is controlled for), so
| I'm admittedly quite skeptical.
|
| The numbers they _do_ publish aren 't particularly
| impressive to me either, so we may also have wildly
| different ideas about what "quite high performance" even
| means.
|
| [1]:
| https://nuetzlich.net/gocryptfs/comparison/#performance
| trasz wrote:
| This is also how the original BSD UFS/FFS was developed
| some three decades ago.
| aidenn0 wrote:
| While the kernel interfaces aren't exactly wildly
| disparate, they are perhaps surprisingly diverse (and
| coupled to kernel implementation details) for something
| as boring as a filesystem. At least some of this is for
| performance reasons. Accessing offsets into kernel
| structures is usually going to be faster than copying the
| data to use on your own.
|
| On top of that, since there is no single standard
| interface in the kernel, kernel maintainers are skeptical
| of adding shims to the mainline kernel. The Linux kernel
| developers are perhaps the most famous for being vocal
| about this, but they are not unique.
|
| That being said, there are portable file system
| implementations that use FUSE. See e.g. NTFS-3g[1]
|
| 1: https://en.wikipedia.org/wiki/NTFS-3G
| nix23 wrote:
| ZFS is pretty portable because of spl ;)
| gizdan wrote:
| > It's a pity that she is working with FreeBSD, or it could
| have been of use to her.
|
| I suppose FreeBSD made more sense as a base considering MacOS
| is derived from BSD.
| the_why_of_y wrote:
| FreeBSD differs quite substantially from the XNU kernel
| used by MacOS because XNU is based on Mach, and it was
| forked (Edit: from 4.3BSD) in 1988 - before Linux even
| existed.
|
| The XNU kernel does not have a stable syscall ABI so
| perhaps it doesn't matter if the syscalls are different
| because the implementation of libSystem can convert as
| appropriate in userspace (see also: WINE).
| throw0101a wrote:
| > _MacOS because XNU is based on Mach, and it was forked
| (Edit: from 4.3BSD) in 1988_
|
| As another commenter noted: XNU = Mach + FreeBSD.
|
| What you are referring to is what NeXTSTEP was, Mach +
| BSD4:
|
| * https://en.wikipedia.org/wiki/NeXTSTEP#Unix
|
| By the time Apple got to them it was a few years later,
| and so they decided to updated that part of the kernel,
| and also brought in FreeBSD's userland.
| nix23 wrote:
| >XNU is based on Mach
|
| Partially, XNU is Mach AND the FreeBSD-Kernel:
|
| https://www.youtube.com/watch?v=-7GMHB3Plc8
| rjzzleep wrote:
| If you look at the source of a lot of drivers on MacOS a
| few years ago, they were heavily based on the FreeBSD
| drivers.
| nix23 wrote:
| Yes sure they do, just look the presentation.
| trasz wrote:
| Could you perhaps relicense your implementation so it could
| be used outside of Linux?
| eafer wrote:
| I don't think I can, I'm using gpl code from other parts
| of the kernel. I'm not sure I would want to either, I put
| a lot of work into this and the gpl gives me more of a
| feeling of ownership.
|
| That said, there's nothing stopping you or anyone else
| from reworking my code into a (gpl-licensed) FUSE driver.
| I don't think it's a straightforward task, but it can
| definitely be done.
| NotEvil wrote:
| I don't think it's a licencing issue. It's implementation
| as both kernels uses different syscalls and have
| different architecture.
| trasz wrote:
| Syscalls are mostly the same, but indeed, the interface
| between the kernel and the file systems is very
| different. However, code which implements that interface
| on the file system is a relatively small part of the
| whole thing; most of the code should be reusable.
|
| Historical note: FreeBSD used to support XFS; I believe
| it was ported from Linux.
| rjsw wrote:
| It takes a lot of work to get the Linux GPU drivers to
| build for other operating systems.
| trasz wrote:
| True. Although it's way easier than it used to be, thanks
| to linuxkpi layer - the piece of FreeBSD kernel which
| implements various Linux kernel APIs.
| ma2rten wrote:
| I think are underestimating in general how much work it is.
| ReactOS has been developed for 23 years and is not in a
| useable state yet.
| cmiller1 wrote:
| However ReactOS has a more challenging/bigger goal for a
| few reasons. It aims to be _binary_ compatible, not just
| source compatible. Much more of the underlying tech is
| proprietary while the BSD subsystem on macOS is free for
| them to use.
| ma2rten wrote:
| "eventual compatibility with x86-64 macOS binaries
| (Mach-O) and libraries"
| infogulch wrote:
| Is there a particular reason to reimplement a proprietary FS (a
| gargantuan task) when FreeBSD already has a world class (cross-
| platform!) FS in ZFS/OpenZFS? Is there something about Mac apps
| that rely on HFS+/APFS-specific features?
| pramsky wrote:
| I assume some of those apps may not work with case sensitive
| file systems. Which I believe is supported by ZFS.
| orra wrote:
| I love an ambitious project like this.
|
| It's a tall order, but sometimes projects like this take off.
| atmosx wrote:
| The problem is lack of support for docker.
| yjftsjthsd-h wrote:
| Apple's MacOD only supports Docker through a virtual machine
| anyways, so it's not like that's any different
| PaulDavisThe1st wrote:
| > source compatibility with macOS applications (i.e. you could
| compile a Mac application on Airyx and run it)
|
| Hard to see how this can be done legally. The libraries (sorry,
| Frameworks) that make up the user-space runtime for macOS are
| all proprietary. There's no replacement for the most important
| parts of it.
| orionblastar wrote:
| Darwin can run limited MacOS applications provided they don't
| use a proprietary Apple MacOS library. Airyx is so limited
| and doesn't have a lot of users to be worth suing over I
| think.
| Bilal_io wrote:
| Probably cheaper and easier for apple to kill them while
| small/young
| michaelmrose wrote:
| They haven't done anything illegal or immoral. Giant
| company tries to use nonsense lawsuits to illegally
| destroy competition doesn't make for great PR.
| nobleach wrote:
| Yeah, if they took the path of ARDI's Executor from the
| 90's, it IS possible to have a completely clean-room
| emulation (of Apple) without violating any intellectual
| property.
| nine_k wrote:
| They are no threat to Apple; Apple's business is selling
| hardware, with software bundled to it.
|
| This is no more menace to them than ReactOS for
| Microsoft.
| michaelmrose wrote:
| A natural pivot if the software was successful would be
| to start selling the hardware with the software putting
| them in direct competition. After all people generally
| don't buy OS they buy computers.
| jhawk28 wrote:
| You would need to reverse engineer what the frameworks are
| supposed to do and provide new implementations. (You can see
| all their external APIs) This is what Google did with Java on
| Android. The courts currently view this as legal (Google v
| Oracle).
| cable2600 wrote:
| The core of MacOS is Darwin which is open source. Based on
| the MACH/XNU kernel and *BSD. So any MacOS clone would
| start with using Darwin code.
| saagarjha wrote:
| Emulating macOS at the Darwin layer is not necessary and
| often not advisable (see: GNUstep).
| PaulDavisThe1st wrote:
| The goal was "source code compatibility with macOS
| applications".
| saagarjha wrote:
| Most Mac apps never call into the Darwin layer directly.
| PaulDavisThe1st wrote:
| Lots of macOS applications need to drop to a few Darwin
| related features from time to time, if only to work
| around bugs in the frameworks. In addition, lots of
| applications run on macOS that use POSIX APIs, which are
| (typically) implemented in Darwin and not in the user-
| space frameworks.
|
| But yet, I misunderstood the GP comment, and what I said
| was not really appropriate in that context.
| spijdar wrote:
| Sure there are (for some definition of "most important
| parts). Take a look at GNUstep for a start. Some MacOS
| frameworks like WebKit are also open sourced from Apple
| itself.
|
| As an example of how this works in practice, the
| disassembler/decompiler Hopper has both MacOS and Linux
| versions that are compiled from the same code.
|
| Now, how successful they'll be extending the open source
| frameworks to made this _useful_ in compiling non-trivial
| software that wasn 't written with "dual compatibility" is a
| fair question, but the starting pieces are there, and
| patching the compilers and creating a copy of MacOS's
| filesystem layout would go a long way in making it easier to
| compile MacOS software on FreeBSD/GNUstep.
|
| And in any event, so far as doing it _legally_ , I don't see
| why this would be any less legal than Wine's recreation of
| the Win32 API/libraries. Only difference is Apple might be
| more litigious than Microsoft, but Microsoft doesn't exactly
| lie down to software theft...
| PaulDavisThe1st wrote:
| GNUStep is not current with the frameworks that it
| corresponds to on macOS (and was never complete).
|
| Those frameworks are also a tiny part of the full set that
| you need to build non-trivial software on macOS.
|
| Audio? Video? so much more stuff that nobody has ever tried
| to reimplement the APIs for.
|
| Yes, such a reimplementation would be legal,but Wine has
| been a project for 20+ years and has a huge headstart
| compared to any idea of doing this for macOS.
| soperj wrote:
| >Some MacOS frameworks like WebKit are also open sourced
| from Apple itself.
|
| It had to be, it was forked from KHtml, which was GPL.
| mkl wrote:
| KHTML is LGPL, as is much of WebKit. If it was GPL,
| Safari would have to be too, instead of proprietary.
| wott wrote:
| > Sure there are (for some definition of "most important
| parts). Take a look at GNUstep for a start.
|
| I was following and trying to use GNUstep 15 years ago, and
| they were constantly chasing a moving target and were not
| managing to catch up. (Plus naturally the reimplementation
| bugs, plus the differences in interpretation of the "spec"
| which forced the programmer to be very careful and not take
| shortcuts.)
|
| That's the huge issue when you are trying to reproduce an
| API which is not under your control by any mean, _and_ is
| still alive and changing.
| 3np wrote:
| This is addressed in the README I linked to. Reimplementation
| of APIs is not legally sketchy. See Oracle vs Google.
|
| https://www.eff.org/cases/oracle-v-google
|
| https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.
| ...
| PaulDavisThe1st wrote:
| To clarify, I didn't mean to imply that reimplementation
| would be a legal issue.
|
| I meant to imply that unlike the case with Windows/Wine,
| there _is no reimplementation of the overwhelming majority
| of macOS APIs_. So if you wanted to do this now, you could
| only do it by copying frameworks directly from macOS (which
| some people are doing for various reasons), and that does
| have some potential legal issues.
|
| Theoretically, a reimplementation is possible. It doesn't
| exist, it's a huge project (far, far bigger than GNUstep),
| and as someone notes down-thread, it's also a moving
| target. There are also uncounted numbers of bugs in the
| current implementation of Apple's APIs, and for many things
| to work correctly you'd need to implement the bugs too
| since developers have designed around them.
|
| Yes, Wine exists. But Wine started in 1993. The idea that a
| bit of hard work by some good developers is going to
| provide a reimplementation of the macOS frameworks in a
| year or three strikes me as without any foundation in
| reality.
| potatolicious wrote:
| Yeah oddly enough that seems like the diciest part of the
| project to me. The Cocoa API is _vast_ , reimplementing
| it isn't necessarily rocket science but would require a
| pretty huge amount of labor.
|
| And you're right - the Cocoa API continues to evolve, so
| if the goal is "source compatible with latest and
| greatest macOS APIs" it's hard to see how a small group
| of open source devs can out-run the sum totality of every
| API engineer at Apple.
|
| I have similar feelings about cross-platform tools like
| Flutter as well - the idea in a vacuum is reasonably
| sound, but then you run into the basic scale problems of
| maintaining compatibility with a moving target - a moving
| target that has >10x more staffing than you do.
| mkl wrote:
| Working second link: <https://en.wikipedia.org/wiki/Google_
| LLC_v._Oracle_America,_...> (it has a "." at the end)
|
| That decision only applies in the USA. I think it will be
| undetermined in many jurisdictions.
| protomyth wrote:
| 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.
| mkl wrote:
| (Edited for clarity)
|
| IBM hasn't been doing that for decades, despite the
| supreme court decision being quite recent - I think that
| was more about clean room reimplementation than APIs.
|
| My point wasn't about ruling differently but the lack of
| rulings/laws making it explicitly legal creating
| uncertainty and opportunities for Oracle/Apple to go
| after people. Some countries have other ways to deal with
| it too, e.g. NZ allows reverse engineering for
| compatibility purposes, which seems likely to cover APIs
| (not sure, haven't needed to know).
| bobsomers wrote:
| > Hard to see how this can be done legally.
|
| Why? Things like Wine and Proton exist and Windows is
| proprietary.
| Jiocus wrote:
| Even ReactOS, an open-source implementation of Windows
| exists.
| PaulDavisThe1st wrote:
| How many years has the Wine project been running?
|
| There is absolutely no equivalent for macOS frameworks.
| GNUStep is a _tiny_ part of the picture, and in addition
| has not kept up with the fairly radical changes that Apple
| has introduced to the frameworks that GNUStep does
| correspond to.
| yjftsjthsd-h wrote:
| That's a practical question, not related to the legal
| question.
| PaulDavisThe1st wrote:
| The legal question I was referring was related to my
| perception that the goal was "source code compatibility
| for macOS applications" _now_ , not after some
| essentially unbounded engineering task.
|
| That may have been incorrect.
| bayesian_horse wrote:
| I think they want to build a new FreeBSD distribution rather than
| "a new operating system". Similar to Ubuntu maybe, but imitating
| MacOs.
|
| They'll probably fail, but that's not the right criterium to
| apply to most projects...
| jaimex2 wrote:
| Apple cease and desist in 3... 2...
| gizdan wrote:
| It looks like the APIs are being reverse engineered, thus even
| if this happens, Apple likely has little legal ground to stand
| on, if at all (IANAL). See also ReactOS[0].
|
| [0] https://reactos.org/
| fluxem wrote:
| Pretty interesting project.
|
| However, who really wants a "global menu bar". It made sense for
| the original mac, when people just used one app at a time. And
| it's left in the current MacOS for legacy reasons. But now people
| usually have multiple 27" monitors. So, instead of having menus
| where the app is, you need to move the mouse all the way to the
| top and then back. Im not sure why anyone would want to replicate
| it.
| DavidSJ wrote:
| One advantage of a global menu bar is that items at the top of
| the screen are effectively an infinitely large target, so you
| can rapidly move the mouse to them without worrying about
| overshooting: https://en.wikipedia.org/wiki/Fitts%27s_law
| fluxem wrote:
| But you want to select a specific menu and not just click
| somewhere on the whole menubar. So, it's no longer an
| infinitly large target and you need precision
| infofarmer wrote:
| They didn't say infinitely large in every direction.
|
| If you're on a Mac now, try quickly hitting the menu bar
| items (at the very top edge of the screen) vs the tabs
| (below the menu bar, not quite at the edge).
|
| I find the difference quite significant.
|
| Peculiarly, this convenience would flip to the opposite if
| the screen were touch-enabled!
| comex wrote:
| You need a precise angle but not a precise speed. I can't
| speak for mice myself, but on my MacBook Pro trackpad, this
| is still much faster. Indeed, if I try to get the mouse
| cursor from somewhere near the middle of the screen to
| somewhere _near_ the top, unless I go very slowly, it 's
| essentially impossible to do it without overshooting and
| hitting the top. At that point I can turn around and move
| the cursor back down to the spot I'm trying to hit, but
| that requires waiting a fraction of a second, or else the
| high speed I accumulated from accelerating quickly will
| 'bounce' off the top and send me too far back down.
|
| ...Honestly, I don't know why the trackpad acceleration
| curve behaves that way. I've never consciously noticed this
| problem before right now, though, so it can't be that bad.
|
| Anyway, of course my experience also differs in that my
| MacBook Pro does not have a 27" monitor. I could be using a
| desktop with a large monitor, but I prefer to be able to
| work from any chair or couch or even lying on the floor. I
| can see why the global menu bar would be more of a
| hindrance with a large monitor. But speak for yourself
| about what people "usually" have. :)
| kitsunesoba wrote:
| I like the menubar being a system-owned fixture (as it is for
| global menubars) because then there's no reason for app
| developers to try to trim away menus or cram them in a "junk
| drawer" hamburger menu in the name of minimalism.
| marcellus23 wrote:
| this this this. On Windows, menu bars are few and far between
| because of this.
| eddieroger wrote:
| > However, who really wants a "global menu bar".
|
| Me? Even when I "use" multiple apps at the same time, I can
| only interact with one at at time in the current keyboard/mouse
| paradigm we're working in, and it's nice to know that when I
| need menu options, they're always in the same place - the top
| left. There's always a context menu available by right/ctrl
| clicking if I'm so inclined and it's properly implemented, but
| in my multiple-monitor setup, I like having the global menu bar
| for when keyboard commands don't cut it.
| nvella wrote:
| I actually find the metaphor quite useful-as a developer I can
| develop a GUI application utilizing a common menu metaphor but
| _not_ always have a window open; essentially an application is
| a 'toolbox', presenting its tools via the global menu, and
| documents/'work' appear as windows. For context, I used Windows
| all my life before switching to Mac about six years ago, and I
| find this makes a lot more sense than one menu per window,
| where application developers often like to go their own way and
| implement their own menu metaphors.
| throw0101a wrote:
| > _However, who really wants a "global menu bar". It made sense
| for the original mac, when people just used one app at a time._
|
| Please still use one app at a time. Try examining what most
| people actually do: they hit maximize on each app and fill the
| screen.
|
| People that tile windows are the exception from my experience.
|
| > _But now people usually have multiple 27 " monitors._
|
| [citation needed]
|
| I'd be curious to see what the numbers are. How many people in
| call centres have that? How many accounting and HR departments?
| steviedotboston wrote:
| how will this diverge from Hello?
| sdrinf wrote:
| Poked around a little bit on the livecd system, screenshots:
| https://imgur.com/a/OsxT3GI
| ChrisMarshallNY wrote:
| As someone who regularly takes on projects that are bigger on the
| inside, than the outside, I wish her well.
|
| It seems well-organized. She has her work cut out for her, but it
| can def be done (I seem to recall a certain trashmouth Finn,
| doing something similar...).
___________________________________________________________________
(page generated 2021-08-05 23:02 UTC)