1,334 karma · joined January 11, 2013
This is why I've always enjoyed Apple products. They don't perform these kind of ridiculous mental gymnastics to justify doing a worse job for their customers.
None. It built a massive teetering edifice of fragile interdependencies that incurs staggering human cost in maintenance, and has almost singlehandedly stood in the way of progress by third-parties that would benefit from working outside that system -- from commercial software vendors to OSS vendors that would prefer to be able to release versions on their own schedule.
If it wasn't for package managers making it possible to maintain fragile dependencies in lockstep, Linux distributions would have been forced to confront simple issues like ABI and API compatibility, third-party distribution, and other basic facets of producing a user-friendly and vendor-friendly OS ... we may have even had a "year of Linux on the desktop" by now.
Instead, we keep throwing humans at the problem of keeping the teetering pile of dependencies operational, largely because of people like you that cargo cult the ideas out of some strange combination of stockholm syndrome and a lack of vision for how things could be better.
Why was anyone was surprised that Google threw away the entire Linux user-space when developing Android?
> So, the user tried to somehow bypass the official distro package management.
... because that's the only way to achieve perfectly reasonable goals as a user.
If I want to install Chrome, guess what it does? It adds an external repository that broke in strange ways when I updated Ubuntu.
> If you open up your microwave oven and electrocute yourself, is that because of a basic flaw of microwave ovens?
Your microwave doesn't refuse to operate unless you only buy food that has been prepackaged by your microwave vendor, that can only be mixed with other food also repackaged by that vendor, and only if all the food has been pre-certified to work together in that exact combination.
You don't need a UNIX package manager for this. See also: every modern OS, ever.
> Dependencies as opposed to static linking will allow the CPU to run and cache used code better instead of reading and discarding the same code from different parts of memory.
You achieve this by having comprehensive base system libraries. See also Android, Mac OS X, iOS.
> Compression will make the handling less IO bound and a bit more CPU intensive, but disks are slow and CPU's are faaaast!
This doesn't need to exist in the package manager. See also HFS+ compression. Bonus: it works without hauling in a huge packaging system.
> If you think it will be slow and complicated, I think you will be in for a pleasant surprise later on.
No, I'll be in for dealing with OSS dependency hell (except that now I can be assured that I'll never use Haiku, because they're actively working to throw away what made the Mac and BeOS designs of that era attractive to begin with, and what they spent 10 years trying to achieve).
It's actually embarrassing that Haiku came so far, only to lose sight of the BeOS R5 target, actively destroying what made BeOS interesting compared to Linux -- especially when modern examples of how to do it right (Android, iOS, Mac OS X) are right in front of them.
This is what happens when Linux kernel engineers wind up in charge of a consumer OS project.
Yes, they don't solve the problem of distributing messy UNIX software with complex and unstable dependency graphs, written for systems with anemic base libraries, that install a litter of files all over your system.
That's a good thing. In fact, I'd say the world would be a better place if we'd never implemented package managers and instead UNIXes were finally forced to clean up their mess. The real world doesn't work that way, so instead the best we can do is create new systems that don't inherit the mistakes of the old.
> I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases.
Use cases like, say, trying a new piece of software that hasn't been packaged?
Getting updates directly from the vendor?
Being able to have their vendor-supplied applications continue to work across major OS releases?
Or how about from the vendor perspective, where we have to deal with mistake-prone volunteers packaging up our software, inconsistent and incompatible libraries and an ever-shifting dependency graph. The only reason anything ever works at all is because there are hundreds/thousands of people whose sole contribution is to keep the entire dependency graph afloat. Just how many human hours do you think are spent on software packaging overhead?
> I solve my problems, you solve yours. Deal with it.
Thanks for elucidating exactly why Linux developed shouldn't be anywhere near the design process for consumer software like an OS.
Answer: unpacking, mounting, managing and downloading dependencies.
> I'm sorry, but I don't think BeOS was ever aimed at someone other than developers. It would be quite surprising if Haiku were aimed at a different public.
The involvement of former Apple employees, targeting Macs, the attempted sale to Apple, the single-user OS, the UI riffing off MacOS, the focus on media, the simple UI -- those we're all flukes? It was actually meant to be a difficult to use Linux clone that focused on shipping packaged UNIX software, despite its particularly weak posix compatibility and complete non-standard directory layout?
I was hacking on BeOS since DR2. I have friends who worked there. It was contemporary with my career, and I was following Apple's and Be's parallel efforts closely. It was, as far as my knowledge and experience goes, a user-focused operating system ala MacOS.
> Maybe you should get some first hand experience and, dare I say, read the manual. If you experience a significantly larger number of disasters than your peers, the problem is most likely not the tooling.
Many years ago, I wrote one one of the package managers in wide use today. Then I spent years shipping software for multiple platforms. I think I understand the trade-offs, and implementing package management only made the underlying failure of the Linux package manager model more clear.
What kind of ridiculous system requires an army of volunteers to maintain a graph of dependencies in lockstep, making it nearly impossible for 3rd party developers to directly release simple binaries that work across their user's systems. Instead we have to add Chrome package repos to our Ubuntu installations that break across major releases.
It's stupid. There are better ways, which are evidenced by the fact that they're working, today, and have been working for some 20 odd years, and are being further defined in the AppStore model.
Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone.
I wouldn't call it simple. It's complex to get right, and outright damaging to non-web clients except in the case where xAuth or similar is available.
> All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach".
No, my criticism can be summed up like so: If you create unnecessary, reducible complexity, then add even more complexity on top of that to manage it, you're doing it wrong.
> It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed.
You're right. It's not.
First of all, note what you said: every developer.
Second of all, note what they're installing: UNIX software. UNIX software is a distribution mess, and it requires a UNIX package manager. If you don't create the mess in the first place, you don't need a package manager to manage it.
Let third-party packaging systems deal with the UNIX packaging mess, and let engineers who need that software deal with the package managers needed to manage it.
Net result: Your users (which includes engineers when they don't have their software development hat on) don't have to deal with the package management disaster unless they need to deal with UNIX software.
QED.
So you're saying that reasoned constructive criticism is not helping?
You can't offer 'help' to people that don't want it. You'll waste your time and theirs.
Are we talking about the same thing? It's a:
- pseudofs
- in userspace (IIRC)
- which parses multiple archive files
- and vends their contents as unionfs
If this bought you anything at all useful, then maybe it would be worth all the complexity involved ... but it doesn't.
> That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs?
It's not punishing developers. I've shipped software for Mac OS, Mac OS X and iOS for 15+ years, and believe me, being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage.
> The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted ...
Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't.
> As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.
Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux.
Yes. Which, ideally, is cheap and easy to do.
> And what about new APIs that come along? Will third-party libraries exist at all, or will users have to wait for an OS upgrade to have applications that can take advantage of them?
We can see how this works today. Third-party libraries exist, application authors benefit from being able to version them at-will (and not be tied to the same version everybody else uses), and if anything grows sufficiently popular/necessary/duplicated, the functionality can be integrated into the OS (an occurrence of which there are numerous examples).
The solution is to provide sufficiently broad set of tightly integrated base system libraries; there are few, if any, duplicate dependencies across most applications.
-- https://news.ycombinator.com/item?id=5567754
The advantage is that you have broad, comprehensive, consistent libraries that integrate with the base system, rather than a mash-up of inconsistent library interfaces and shell scripts -- for example, see how Linux distributions manage OpenSSL and certificate authorities, versus how OS X and Windows both integrate their crypto libraries into the system certificate stores and UIs.
To use OpenSSL as an example, on OS X applications all make use of SecureTransport and CommonCrypto. This brings other advantages, such as automatic integration with keychain-managed certificates and certificate authorities.
Apple has moved to solve this problem in iOS (and the Mac App Store) by maintaining per-app metadata directories. I think this is ideal, and it's not necessary to attach it to the app store model.
> More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries.
Yes, UNIX software.
> Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files).
That's what the file system is on a system that manages applications sanely.
Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day.
This doesn't work for software build/distributed via the UNIX model, but that's the whole point -- if you don't use the UNIX approach to distributing end-user software, you don't create a problem that requires a package manager to solve.
Retrieving data from multiple on-disk compressed package archives and presenting them as a union pseudofs is a heck of a lot more overhead than hitting the file system directly.
> As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it.
Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end.
The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all.
It's really depressing to see Haiku come so close to completion, only to have project direction taken over at the very end by Linux developers (literally, that's their day job), who are bringing Linux ideals to a system that was originally built as a successor to the original Mac OS.
> Lack of ui/ux contributors?
It's really both of these. For a long time, the constraint was fidelity with BeOS R5, which kept focus on an achievable goal.
However, there has been some interest in making UX/UI improvements; the problem seems to be that there just isn't much (if any) design/UX expertise in the open source community.
DMG is an archive distribution format. The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software.
Think FUSE.
> The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems.
First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs.
Second of all, the problem isn't the PATH thing. The problem is a huge dependency graph of non-ABI stable libraries and packages that are comprised of a ton of files splatted over the disk.
If you get rid of the non-ABI-stable libraries, and don't splat your files everywhere, you don't need some crazy pseudofs-based package manager to manage your software.
Problem solved. No package management (in the Linux sense) required. Isn't it a good thing to remove unneeded, reducible complexity?
The problem is the legacy UNIX practice of splatting files all over the drive and having an unstable dependency graph. Fix that, and you don't need a UNIX package manager.
You only need a traditional UNIX package manager if you have traditional UNIX packages -- splatting files all over the file system, providing unstable ABI/API, etc.
The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux. You'd think they'd at least borrow from the modern app store idea of "packages".
They're actually implementing package management as a paid project. I'm seriously annoyed that my donation to Haiku is being spent on that, rather than on things that would actually matter to existing desktop users coming from Mac OS X. It seems that Haiku has floundered, largely due to the take-over of Linux-centric developers after the original project leader (Michael Phipps) left in 2009. Michael kept the project very focused on BeOS R1, and now it's all over the map and pulling in the very ideas from Linux that BeOS and MacOS were built in opposition to.
What does this have to do with evaluating papers? Why would we divert ourselves from a technical mission to pick up an unrelated social cause?
> The so-called meritocracy you think exists does not. Its just structural discrimination of a different stripe.
The place to worry about correcting structural discrimination isn't at the point where it's already happened. That correction would be artificial and as such, detrimental to furtherance of our art and science.
The time to correct structural discrimination is long before anyone is submitting papers to present research they've already done.
Did this actually improve the technical content of the conference, or did it simply redefine the objective measure by which PyCon determines "success" to include non-technical metrics? The latter seems to be the case, in which case, it's not a particularly valuable stratagem for a merit-focused technical conference.
Operating systems? No. Sorry. Operating systems, as a rule, predate modern practices by some 1-4 decades. Making a kernel like Linux, Darwin, or FreeBSD testable would be a task somewhere between "massive headache" and "really massive headache". I've done some in-kernel unit testing, but only on our own driver subsystems that could be abstracted from the difficult-to-test underlying monolithic code base.
Outside of kernels/operating systems, just Google. Unit/automated testing is prevalent in just about all modern OSS software ecosystems.
A few examples, off the top of my head.
Apache APR: http://svn.apache.org/viewvc/apr/apr/trunk/test/README?revis...
Clang: http://llvm.org/svn/llvm-project/cfe/trunk/test/
Go: https://code.google.com/p/go/source/browse/src/pkg/math/all_... (see all *_test.go files)
What exactly makes you think there aren't?
It shipped. That doesn't prove your point. Code that is expensive to produce and ships is better than no code at all. That doesn't mean that this is the best way to produce code.
What exactly do you think is awesome about the code?
> I, personally, would be more than happy to have produced the 'crap' BSD code that has propelled Apple into one of the most valuable companies today.
I did produce some of that code.
Nothing that you're saying justifies why producing worse code, less efficiently, is better than producing good code, more efficiently. Your position assumes a false dichotomy where the choice is between shipping or not shipping.
The truth of the matter is that the legacy approach to software development used in those industries has more to do with the historical ignorance of better practices and the resulting modern cultural and technical constraints. In the era that most of that code was originally architected, it was also normal to write C programs with all globals, non-reentrant, and non-thread-safe. Are you going to claim that this is also the best way to write code, just because it produced some mainstays of our industry?
What is a 'starting point'? Open source certainly doesn't provide equal starting points, because each individual is evaluated on merit, the acquisition of which is often tied to social and economic background.
Conferences don't provide equal starting points, for the same reason.
> Egalitarianism and meritocracy are not mutually exclusive nor orthogonal.
They are orthogonal. An egalitarian meritocratic society would give each member equal opportunity to achieve, but would judge the achievements of each member according to their merit.
Open source only concerns itself (like any sane organization whose mission is not social advancement) with merit, not with egalitarian questions of how merit was acquired.
I have. The only reason they work at all is the enormous number of man years spent banging on the poorly tested code after its written. The number of regressions that pop up in core subsystems of the kernel are staggering. VM bugs still happen in commercially shipping systems like OS X because of small changes to extremely fragile and untested code.
Linux isn't a paragon of code quality, and neither are most Network stacks. If anything, you're proving my point -- code written in that methodology has required enourmous amounts of work to stabilize and prevent/fix regressions going forward.
Case in point; a few years ago, I found a trivial signed/unsigned comparison bug but in FreeBSD device node cloning that was triggered by adding/removing devices in a certain order; this triggered a kernel panic, and took teo days to track down. The most trivial of unit tests would have caught this bug immediately, but instead it sat there languishing until someone wrote some network interface cloning code (me) that happened to trigger this bug faaar down below the section of the kernel I was working in.
This kind of thing happens all the time in the projects you list, and its incredibly costly compared to using testing to not ship bugs in the first place.
At 'serious' technical conferences, presentations are based on papers, papers are based on work already done. The conference itself is an end game of months or years of work that already happened.
At less serious conferences, talks, presentations, and panels are selected to maximize interest by choosing people of significant stature and interest in the community. Again, this is the end game of months or years of work that already happened.
Where is it the conferences responsibility (and to what advantage) to extend themselves to garnering talks and presenters from a minority industry segment (and which minority segments?). Do you actually have demonstrable evidence that presenters and papers of merit are being excluded from conferences? This would serve as evidence that conferences were failing in the missions to provide top tier content.
It seems that your position is focused more on who is presenting content than what the content actually is.