Agreed. Saying "exceptions have no place in the kernel" is stupid - a good table-based exception ABI can be have zero cost except when an error occurs. It's not one or the other, if you're expecting a call to fail frequently use an error code return.
Windows SEH is really quite neat, and sometimes I wish Linux had a similar feature (though I'm not convinced the complexity is worth it). The Windows kernel actually converts access violations/illegal instructions etc into exceptions and then unwinds the user-mode thread stack. You can throw/catch exceptions from C.
I think a lot of people who don't like exceptions probably don't understand exception safety properly, or were brought up on Java exceptions where every method ends up with "throws Exception" on the end to hack around checked exceptions.
You apparently need to research the idea of "trusted desktops". Ctrl-Alt-Delete in Windows is intercepted by the kernel and triggers a switch to a secure window station (basically, a separate desktop). Unless you can compromise the kernel you can't get a window onto this secure desktop.
Copy and paste between Qt and GTK 2 apps should work fine, if it doesn't there is a bug in your setup somewhere. But yes I agree, software installation is a pain.
Yet Another Package Format is not what Linux needs.
autopackage isn't "yet another package format". It's one that is universal - you can build one autopackage, and it'll install anywhere. Just like an MSI will install on any Windows (with the appropriate runtime, except that autopackages will install the runtime for you on first use).
It's not necessarily easy, mind you. Developers have to put a bit of work in to ensure their software is easy to install. But it can be done.
Drivers would still be a cost. Did you not read the post by Alan Cox saying that we actually have specs for some 3D cards but no drivers, simply because developing 3D drivers is such a non-trivial thing to do? There are very few people who can do it.
There's a tendency to think that the open source community has unlimited manpower and expertise. If the whole software industry was based on open source development this still would not be true, but as it is our man power definitely is limited. So you have to remember that.
It's easy to say, "what if". What if rather than the hopelessly inelegant Objective-C/C/Java combo MacOS X uses, it had been written entirely in Lisp as the old Symbolics machines were? (reason lisp failed: performance and cost). What if the moon was made of cheese?
You are apparently not following the situation, whereas I am. The GCC ABI is still buggy and still being broken - gcc 3.4 has a different C++ ABI to gcc 3.3 and 3.2: there are no guarantees it won't break again.
That'll be because no-one targets the Mac with spyware or viruses, because Windows is a soft enough target and has vastly more market share; it's not worth their while to yet.
Yes indeed. Given Apples history of remote code execution via web pages in Outlook stylie (look up the disk:// and help exploits), I think the only thing really "protecting" the Mac is statistical irrelevance. Same is true of Linux to some extent.
You can run Photoshop using CrossOver. There are a ton of apps that aren't ported yet or may never be ported - for these, Wine is the only way forward.
C++ is a fine language for writing *applications*, it's a shit language for writing *libraries*. There has never been a stable C++ ABI, and although progress is being made towards one no shipping desktop today except KDE exposes raw C++ objects in its libraries. This is for good reasons - it makes binary distribution an absolute nightmare. Even Windows doesn't do this.
The right way to do libraries in the absence of a C++ ABI (and anyway, most languages can't easily interop with C++) is to produce an object-oriented C based ABI like... hmm... GObject!
The open source community doesn't have as good of a reason to improve the usability as Apple does. Apple is a business and needs to make money, the various Linux gui maintainers, a community project, do not.
That clearly is not true - a lot of the people driving usability for GNOME are working for Red Hat, Novell, and Sun. They want a desktop system they can sell to the corporate world and that has to be easy to use.
I'm a Wine developer and I can tell you there's a galaxy of difference between running a version of Notepad compiled for PPC natively and running real world applications at a useful speed from the binaries factoring in eg copy protection support. I wouldn't hold your breath.
No they aren't, that's totally false. There are no Apple engineers working on Wine, unless they hide who they work for.
Wine doesn't even run on MacOS. Winelib (so apps for which you have the source) has run once or twice, then it breaks again.
Anyway, I don't know where the grandparent gets off saying Wine doesn't work on Linux. Lots of people use it to run MS Office, Photoshop, CounterStrike, Lotus Notes, various other games and so on - there are lots of people out there who can only use Linux because of it.
The original Mac menubar might have obeyed Fitts law because the most commonly accessed menus were always in the same place. Since they introduced a menu with the applications name, that fact is no longer true and so any usability advantage it once had has been lost. Nowadays it's just a relic from the early days that they can't remove for branding reasons.
The Mozilla Project maintains a database of them. Search bugzilla for tech evangelism - last time I did that there were over 2500 registered sites that didn't work, many of them very high profile and popular.
As for the rat's nest of cables, I really don't see it being as bad as you say. There are pretty much the same level of cables either way. Power, video, keyboard, mouse, audio, external devices like a USB camera.
Indeed, simply making everything use USB doesn't magically make cabling disappear. It's actually a disadvantage: if I bought a Mac the first thing I'd do would be to buy a 3 button wheel mouse. I already have one that I like very much but it's PS/2 not USB. This does not make it 'inferior', sorry, I plug it in and it works and never breaks so as far as I'm concerned using USB would not be an advantage. USB can be a disadvantage: I've known one Mac user who had to rewire his setup with extra hubs and such because he bought some USB speakers and when combined with his mouse/keyboard and other peripherals the bus was overloaded and mouse/keyboard events got lost!
OK, so now I'm posting, I might as well list the other reasons I'd not switch to MacOS from Linux:
Usability. Sorry but I don't find MacOS X usable. I find it doesn't work the way I expect - simple, basic things like apps not quitting when you close the last window run counter to my 10+ years of experience. You don't unlearn such things quickly, or at least I don't, and the fact that I would have to annoys me: I can't think of a single advantage such an approach has. Likewise for the single menubar; in the OS 9 days this made sense as File, Edit etc would always be in the same place so allowing you to harness muscle memory. Then Apple demonstrated that they no longer understood usability and put the app name as the first item, which changes everytime you switch apps so destroying the point.
MacOS does do some things very well, and often works the way I expect, however it has a lot of historical baggage I'd rather do without. The non-standard keyboard also irks me. Linux on the other hand is much more semantically compatible with Windows in terms of UI, keyboard shortcuts, and so on. Usability isn't interesting to me in the abstract sense: it's about making my day easier. MacOS X doesn't, regardless of how simple it makes some tasks.
Consistency and theming: Linux lets me theme everything, yet is nearly always consistent. This may be surprising to some readers but I use unified themes to make Qt and GTK+ play together, and these days portable apps like Firefox and OpenOffice can track native theming as well. Only very rarely do I use an app that doesn't follow the native theme. On Linux though I can theme not only widgets but also stock artwork, window borders, and I can use SVG scalable icons for my desktop. I like that because I have a flat panel screen which only looks crisp at high resolutions.
Some people hate theming and say it makes things non-consistent, but that's like saying you hate putting posters on walls or art in your room. My desktop is a personal space, I enjoy giving it a personal touch and when I get bored, redecorating. However, it's important that generally apps are consistently themed (I make an exception for XMMS) otherwise they are distracting to me.
Mac fails both of these tests. You can't theme it without fragile 3rd party hacks which tend to break stuff (or the ones a friend tried did). Nonetheless, it's not consistent - some apps are Aqua and some are brushed metal. It's like living in a hotel where you can't decorate the room yet one wall is blue and the other is red. It is just jarring to my sense of aesthetics. The other thing that annoys me about this is that Apple did this because to them it looks cool and they want to sell Macs, but they didn't just admit this they had to rewrite their HIG to try and give it some lame justification. I think it was related to apps that are equivalent to real world objects. Safari obviously ignores that rule too.
Games. I'm not a big gamer, but I do have one or two games that I tend to play in the 15-20 minute gaps you sometimes get in a day. I really like Supreme Snowboarding - it
You're mixing two things here. First, Apple has to abide by the restrictive GPL, and they do.
Actually KHTML is LGPL licensed, not GPL licensed.
However, nowhere does the GPL say you have support the code you borrowed from. If the modified Apple code doesn't work on KDE, tough luck.
Correct. Apple is clearly not interested in supporting the open source community, only taking from it what they can to push their own proprietary operating system forward - this type of community hijacking is a rather disturbing trend.
They did it for FreeBSD (last I heard FreeBSD got some test cases and a couple of minor bugfixes out of it, and that's that), now KHTML which was forked in secret and developed so fast that the resulting patch dump was unusable - remember that KHTML has been extended to use proprietary Apple APIs so it's not just a case of dropping it into KDE CVS.
Even if it was, that'd be pissing all over the volunteer developers who added features whilst Safari was under development only to find that Apple duplicated their work. Not a pleasant situation for a project to be in. I hate to say it, but probably KHTML is dead code : the changes Apple make constantly are undocumented, so who in their right mind would want to spend their evenings and weekends hunting through enormous patch dumps extracting changes rather than writing code - but equally, who wants to make improvements already made?
He's talking about operating system lockin, though yes hardware lockin is a concern as well (obviously).
Why does Windows have a monopoly? Lots of reasons but the main one is the apps, it's that simple. People need Windows to run their apps, so they buy it even if they hate it.
Apple MacOS is exactly the same in that respect. It's economically exactly the same as Windows in that respect - that's why Macs have no chance at the corporate desktop: there is no economic incentive... Mac to Windows is as Coke to Pepsi, or McDonalds to Burger King. Affectionados of both may argue about the differences all day long, but they're distinguished by the similarities rather than the differences. A world based on MacOS rather than Windows would not be better especially as it's unlikely Apple would have developed OS X if selling System 9 was still a goldmine.
1- 14K+ employees workin in the OS? I don't think so.
Last accurate figures we have date from late 2000 and suggest there were 5000 odd people working on Windows (that includes testers and documenters, iirc). They hit management limits at that point, but apparently since then were able to scale the project up even further meaning there's probably about 6000-7000 full time employees working on Windows now.
I'd say that making the kernel of their premier product open-source when they didn't have to...
They got no benefit from keeping it closed. It wasn't theirs to begin with anyway, so by making it open source they might get some free bugfixes from people but they don't have a great deal of investment in Darwin and by itself, it's useless for actually running Mac apps. So they don't lose anything, only gain. They still control the Mac platform.
* Apple's native compiler is GCC.
So what? The same is true of many vendors of proprietary embedded systems. GCC is used all over the place. Now, they have contributed back improvements to GCC. This is, to be frank, probably their most useful open source contribution.
* Apple's browser is based on an open-source core.
Because writing their own rendering engine made no sense. Note that Safari itself isn't open source, because they didn't have to do that and it would not have gained them anything (they wanted to sell it as an upgrade incentive).
* Apple's directory services are open source.
Only useful if you're an Apple customer
* They've open-sourced their streaming server.
But not their client, which is what everybody actually wanted - cue reverse engineering of codecs and QuickTime for Windows being used on Linux.
* Darwin is more than just BSD and Mach, it includes IOkit and lots of drivers. Have a look at the open source code in Mac OS X 10.3.5 here:
Drivers for Apples hardware, mostly. But yes, the drivers can be useful.
This would be like Microsoft open-sourcing the NT kernel, the MS HTML control (which is almost all of IE), their compilers (even if not the IDE), Active Directory, huge chunks of Win32, IIS, and Windows Media Server.
No it wouldn't. For starters, Microsoft actually developed the NT kernel, Trident (MSHTML), Win32, IIS and so on themselves. Apple did not develop their own kernel, rendering engine, or web server. They weren't theirs to open source.
Win32 is a bogus point, the Mac APIs aren't open either (duh) - how many Mac apps only use POSIX? Virtually none, right? How many use Cocoa or Carbon, which are vast proprietary APIs? Lots, right? When Apple bought shake and killed the Linux port, did people simply compile the MacOS X libraries for Linux and carry on? I think not.
Who says patents are necessarily good for other technical fields? After the steam excavator was patented the technology stagnated for 50 years until the patent expired, at which point they were deployed through the mining industry and developed rapidly.
Yeah, pretty much agreed. One problem with having a bazillion distros is that bugs in configuration have to be fixed over and over again, and some users will never get them. Random example, Fedora/Red Hat uses pam_xauth to migrate X11 authentication information across "su" sessions. It means you can use su and not have any problems with X apps, It Just Works. But, even though this is a simple change to make, other distros use a variety of hacks developed before pam_xauth and never replaced like sux, manual xhost fiddling, and so on.
Likewise, distro A may be able to detect network card B, but distro C cannot. Is the user of distro C really served better through the "choice" of having a working vs non-working network card?
The distro system serves a purpose, but people write off the disadvantages with vague rants about "choice" and "freedom" without attempting rational debates as to the disadvantages.
If distributions are using config files incompatible or non-existant upstream then this has to be fixed. It doesn't really matter if you edit them directly or use a GUI, the end result should be compatible and in most cases is. The exceptions tend to be things like init scripts which aren't yet upstreamed in a sensible fashion.
Given that I maintain autopackage, which is devoted to distribution-neutral binary packages, and work on CrossOver which has to operate on many different distributions, probably more than you have.
When I was talking about differences between them, I was talking about the actual software that makes them up. If you look at desktop distros (ie ignore issues like corporate support for servers and specialist router distros), the biggest differences from a software vendors perspective are:
The package manager/dep resolver in use
The packages/versions that are actually installed
The custom patches applied
The other differences like config tools aren't really relevant, and are slowly being reduced as more and more software is pushed upstream.
From the users perspective then, the biggest differences are packages + how much work they make you do. I'd object to your characterisation of SuSE (and I guess similar distros like Fedora or Mandrake, or indeed Ubuntu) as being a "real pain in the ass" if you "know what you're doing". I like to think I know what I'm doing, I've certainly written enough software to prove it, and I use Fedora. Likewise, some of the best hackers I know are using SuSE or Fedora.
The differences from a users perspective don't concern me so much as differences from a software vendors perspective. A 'vendor' in this case can easily be an open source project on SourceForge as well as a proprietary developer. These manifest in the packages installed in a base profile, and the patches applied to key components. I'd much rather that distros didn't patch things at all to be frank - experimentation is fine but there's far too much custom patching going on in distros that could just as easily be done upstream, but working with upstream is hard because they might want things done in a particular way or style, so the end result is you get lots of distros that hardly vary at all with no real standardisation or consistency. This is harmful.
Windows SEH is really quite neat, and sometimes I wish Linux had a similar feature (though I'm not convinced the complexity is worth it). The Windows kernel actually converts access violations/illegal instructions etc into exceptions and then unwinds the user-mode thread stack. You can throw/catch exceptions from C.
I think a lot of people who don't like exceptions probably don't understand exception safety properly, or were brought up on Java exceptions where every method ends up with "throws Exception" on the end to hack around checked exceptions.
You apparently need to research the idea of "trusted desktops". Ctrl-Alt-Delete in Windows is intercepted by the kernel and triggers a switch to a secure window station (basically, a separate desktop). Unless you can compromise the kernel you can't get a window onto this secure desktop.
Copy and paste between Qt and GTK 2 apps should work fine, if it doesn't there is a bug in your setup somewhere. But yes I agree, software installation is a pain.
autopackage isn't "yet another package format". It's one that is universal - you can build one autopackage, and it'll install anywhere. Just like an MSI will install on any Windows (with the appropriate runtime, except that autopackages will install the runtime for you on first use).
It's not necessarily easy, mind you. Developers have to put a bit of work in to ensure their software is easy to install. But it can be done.
There's a tendency to think that the open source community has unlimited manpower and expertise. If the whole software industry was based on open source development this still would not be true, but as it is our man power definitely is limited. So you have to remember that.
It's easy to say, "what if". What if rather than the hopelessly inelegant Objective-C/C/Java combo MacOS X uses, it had been written entirely in Lisp as the old Symbolics machines were? (reason lisp failed: performance and cost). What if the moon was made of cheese?
You are apparently not following the situation, whereas I am. The GCC ABI is still buggy and still being broken - gcc 3.4 has a different C++ ABI to gcc 3.3 and 3.2: there are no guarantees it won't break again.
Yes indeed. Given Apples history of remote code execution via web pages in Outlook stylie (look up the disk:// and help exploits), I think the only thing really "protecting" the Mac is statistical irrelevance. Same is true of Linux to some extent.
You can run Photoshop using CrossOver. There are a ton of apps that aren't ported yet or may never be ported - for these, Wine is the only way forward.
The right way to do libraries in the absence of a C++ ABI (and anyway, most languages can't easily interop with C++) is to produce an object-oriented C based ABI like ... hmm ... GObject!
That clearly is not true - a lot of the people driving usability for GNOME are working for Red Hat, Novell, and Sun. They want a desktop system they can sell to the corporate world and that has to be easy to use.
I'm a Wine developer and I can tell you there's a galaxy of difference between running a version of Notepad compiled for PPC natively and running real world applications at a useful speed from the binaries factoring in eg copy protection support. I wouldn't hold your breath.
Wine doesn't even run on MacOS. Winelib (so apps for which you have the source) has run once or twice, then it breaks again.
Anyway, I don't know where the grandparent gets off saying Wine doesn't work on Linux. Lots of people use it to run MS Office, Photoshop, CounterStrike, Lotus Notes, various other games and so on - there are lots of people out there who can only use Linux because of it.
The original Mac menubar might have obeyed Fitts law because the most commonly accessed menus were always in the same place. Since they introduced a menu with the applications name, that fact is no longer true and so any usability advantage it once had has been lost. Nowadays it's just a relic from the early days that they can't remove for branding reasons.
The Mozilla Project maintains a database of them. Search bugzilla for tech evangelism - last time I did that there were over 2500 registered sites that didn't work, many of them very high profile and popular.
Indeed, simply making everything use USB doesn't magically make cabling disappear. It's actually a disadvantage: if I bought a Mac the first thing I'd do would be to buy a 3 button wheel mouse. I already have one that I like very much but it's PS/2 not USB. This does not make it 'inferior', sorry, I plug it in and it works and never breaks so as far as I'm concerned using USB would not be an advantage. USB can be a disadvantage: I've known one Mac user who had to rewire his setup with extra hubs and such because he bought some USB speakers and when combined with his mouse/keyboard and other peripherals the bus was overloaded and mouse/keyboard events got lost!
OK, so now I'm posting, I might as well list the other reasons I'd not switch to MacOS from Linux:
MacOS does do some things very well, and often works the way I expect, however it has a lot of historical baggage I'd rather do without. The non-standard keyboard also irks me. Linux on the other hand is much more semantically compatible with Windows in terms of UI, keyboard shortcuts, and so on. Usability isn't interesting to me in the abstract sense: it's about making my day easier. MacOS X doesn't, regardless of how simple it makes some tasks.
Some people hate theming and say it makes things non-consistent, but that's like saying you hate putting posters on walls or art in your room. My desktop is a personal space, I enjoy giving it a personal touch and when I get bored, redecorating. However, it's important that generally apps are consistently themed (I make an exception for XMMS) otherwise they are distracting to me.
Mac fails both of these tests. You can't theme it without fragile 3rd party hacks which tend to break stuff (or the ones a friend tried did). Nonetheless, it's not consistent - some apps are Aqua and some are brushed metal. It's like living in a hotel where you can't decorate the room yet one wall is blue and the other is red. It is just jarring to my sense of aesthetics. The other thing that annoys me about this is that Apple did this because to them it looks cool and they want to sell Macs, but they didn't just admit this they had to rewrite their HIG to try and give it some lame justification. I think it was related to apps that are equivalent to real world objects. Safari obviously ignores that rule too.
Actually KHTML is LGPL licensed, not GPL licensed.
However, nowhere does the GPL say you have support the code you borrowed from. If the modified Apple code doesn't work on KDE, tough luck.
Correct. Apple is clearly not interested in supporting the open source community, only taking from it what they can to push their own proprietary operating system forward - this type of community hijacking is a rather disturbing trend.
They did it for FreeBSD (last I heard FreeBSD got some test cases and a couple of minor bugfixes out of it, and that's that), now KHTML which was forked in secret and developed so fast that the resulting patch dump was unusable - remember that KHTML has been extended to use proprietary Apple APIs so it's not just a case of dropping it into KDE CVS.
Even if it was, that'd be pissing all over the volunteer developers who added features whilst Safari was under development only to find that Apple duplicated their work. Not a pleasant situation for a project to be in. I hate to say it, but probably KHTML is dead code : the changes Apple make constantly are undocumented, so who in their right mind would want to spend their evenings and weekends hunting through enormous patch dumps extracting changes rather than writing code - but equally, who wants to make improvements already made?
Why does Windows have a monopoly? Lots of reasons but the main one is the apps, it's that simple. People need Windows to run their apps, so they buy it even if they hate it.
Apple MacOS is exactly the same in that respect. It's economically exactly the same as Windows in that respect - that's why Macs have no chance at the corporate desktop: there is no economic incentive ... Mac to Windows is as Coke to Pepsi, or McDonalds to Burger King. Affectionados of both may argue about the differences all day long, but they're distinguished by the similarities rather than the differences. A world based on MacOS rather than Windows would not be better especially as it's unlikely Apple would have developed OS X if selling System 9 was still a goldmine.
Last accurate figures we have date from late 2000 and suggest there were 5000 odd people working on Windows (that includes testers and documenters, iirc). They hit management limits at that point, but apparently since then were able to scale the project up even further meaning there's probably about 6000-7000 full time employees working on Windows now.
Where is the source to RHN Satellite Server?
They got no benefit from keeping it closed. It wasn't theirs to begin with anyway, so by making it open source they might get some free bugfixes from people but they don't have a great deal of investment in Darwin and by itself, it's useless for actually running Mac apps. So they don't lose anything, only gain. They still control the Mac platform.
* Apple's native compiler is GCC.
So what? The same is true of many vendors of proprietary embedded systems. GCC is used all over the place. Now, they have contributed back improvements to GCC. This is, to be frank, probably their most useful open source contribution.
* Apple's browser is based on an open-source core.
Because writing their own rendering engine made no sense. Note that Safari itself isn't open source, because they didn't have to do that and it would not have gained them anything (they wanted to sell it as an upgrade incentive).
* Apple's directory services are open source.
Only useful if you're an Apple customer
* They've open-sourced their streaming server.
But not their client, which is what everybody actually wanted - cue reverse engineering of codecs and QuickTime for Windows being used on Linux.
* Darwin is more than just BSD and Mach, it includes IOkit and lots of drivers. Have a look at the open source code in Mac OS X 10.3.5 here:
Drivers for Apples hardware, mostly. But yes, the drivers can be useful.
This would be like Microsoft open-sourcing the NT kernel, the MS HTML control (which is almost all of IE), their compilers (even if not the IDE), Active Directory, huge chunks of Win32, IIS, and Windows Media Server.
No it wouldn't. For starters, Microsoft actually developed the NT kernel, Trident (MSHTML), Win32, IIS and so on themselves. Apple did not develop their own kernel, rendering engine, or web server. They weren't theirs to open source.
Win32 is a bogus point, the Mac APIs aren't open either (duh) - how many Mac apps only use POSIX? Virtually none, right? How many use Cocoa or Carbon, which are vast proprietary APIs? Lots, right? When Apple bought shake and killed the Linux port, did people simply compile the MacOS X libraries for Linux and carry on? I think not.
Who says patents are necessarily good for other technical fields? After the steam excavator was patented the technology stagnated for 50 years until the patent expired, at which point they were deployed through the mining industry and developed rapidly.
Likewise, distro A may be able to detect network card B, but distro C cannot. Is the user of distro C really served better through the "choice" of having a working vs non-working network card?
The distro system serves a purpose, but people write off the disadvantages with vague rants about "choice" and "freedom" without attempting rational debates as to the disadvantages.
If distributions are using config files incompatible or non-existant upstream then this has to be fixed. It doesn't really matter if you edit them directly or use a GUI, the end result should be compatible and in most cases is. The exceptions tend to be things like init scripts which aren't yet upstreamed in a sensible fashion.
Given that I maintain autopackage, which is devoted to distribution-neutral binary packages, and work on CrossOver which has to operate on many different distributions, probably more than you have.
When I was talking about differences between them, I was talking about the actual software that makes them up. If you look at desktop distros (ie ignore issues like corporate support for servers and specialist router distros), the biggest differences from a software vendors perspective are:
The other differences like config tools aren't really relevant, and are slowly being reduced as more and more software is pushed upstream.
From the users perspective then, the biggest differences are packages + how much work they make you do. I'd object to your characterisation of SuSE (and I guess similar distros like Fedora or Mandrake, or indeed Ubuntu) as being a "real pain in the ass" if you "know what you're doing". I like to think I know what I'm doing, I've certainly written enough software to prove it, and I use Fedora. Likewise, some of the best hackers I know are using SuSE or Fedora.
The differences from a users perspective don't concern me so much as differences from a software vendors perspective. A 'vendor' in this case can easily be an open source project on SourceForge as well as a proprietary developer. These manifest in the packages installed in a base profile, and the patches applied to key components. I'd much rather that distros didn't patch things at all to be frank - experimentation is fine but there's far too much custom patching going on in distros that could just as easily be done upstream, but working with upstream is hard because they might want things done in a particular way or style, so the end result is you get lots of distros that hardly vary at all with no real standardisation or consistency. This is harmful.