Ingo Molnar on what ails the Linux desktop - <AUTHOR> https://plus.google.com/109922199462633401279/posts/HgdeFDfRzNe <comment> muuh-gnu The reason I stopped recommending Linux to "normal users" is _because_ of the concept of distributions.

Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. Having to upgrade the whole distro (including all the other installed apps you dont want to upgrade) just to install a new version of one single app you _want_ to update is a nightmare. Total bullshit. Users. Dont. Want. That. Users dont want one update to trigger another update, or even to trigger the upgrade of the whole desktop.

The blog post by ESR is one prominent example: <http://esr.ibiblio.org/?p=3822>

He basically wanted to upgrade just one (obscure) app, and the process triggered the automatic removal of Gnome2 and installation of Unity. Just _IMAGINE_ how nightmarish this must look for normal users. You simply dont remove somebodys installed desktop sneakily from under their feet. You simply dont. That feels like the total loss of control over your computer.

I personally had, during the last 10 years, people go from Linux (which I talked them into trying) back to windows, _precisely_ of this reason, of having to upgrade the whole distribution every few months just to be able to get new app versions. They dont have to put up with this insane bullshit on Windows, why should they put up with it on Linux?

This "distribution" bullshit is not what is killing desktop Linux, it is what _already_ killed desktop Linux.

The other reasons why desktop Linux never made it (no games, no preinstallations on hardware) are imho just consequences of the distribution concept and the 6-month planned-obsolescence cycle. Nobody wants to bother with something which will be obsolete half a year down the road. Nobody wants to develop for a target that moves _that_ fast.

Windows installations, once installed or preinstalled, run for a decade. Develop something, and it will run on a 10 yr old Windows your grandparents use. Most people encounter new Windows installations only when they buy a new computer. PC manufacturers know that customers will hate it when their new computer OS is obsolete within half a year and that they wont be able to install new apps, so they dont preinstall Linux, it's as simple as that.

If anybody _ever_ really wants to see Linux succeed on the desktop (before the desktop concept itself is gone), he will have to give up on the distribution concept first.

<comment><USER3> But what is the alternative to a non-distributions based gnu linux operating system?

How do you manage the 1000 packages and their libraries and dependencies? Many of them have separate runtimes which may or may not depend on the other packages runtime. How would you design an application sandbox to cover them all?

What you're saying basically is that linux is failed. At least for me, since I cant see another way to distribute and manage the massive amount of packages that sit on gnu.org.

I agree with you, and It is my opinion that the one who solves these problem is in for a lot of business-opportunities.

<comment><USER4> 0-install (<http://0install.net/>) or even better - Nix packaging system (<http://nixos.org/nix/> \- they claim to be a purely _functional_ package manager)

<comment><USER5> Damn straight! I don't understand why so few people know about Nix.

I'm hoping Nix(OS) will take off eventually. I try to play with it from time to time, but I haven't made the investment yet to really contribute.

<comment><USER4> maybe if someone would build a tool that pulls from Ubuntu repository and recreates an equivalent nix package.

come to think of it, there is nothing in aptitude that prevents this kind of an approach (including the unique hash paths). It will get you to 75% of Nix functionality, which IMHO is good enough.

I dont think Redhat.or Ubuntu will want to do that though. Their business model revolves around the walles garden.

</comment></comment></comment></comment></comment><comment><USER6> The solution for this is quite simple: split the distro to a core, and a separate 'apps' repository, and let app authors control (but with a mandatory QA step) when their software gets released or updated. We did this with Maemo (and later MeeGo), and it has worked great: [http://bergie.iki.fi/blog/application_quality_assurance_in_l...](http://bergie.iki.fi/blog/application_quality_assurance_in_linux_distributions/)

Cross-distro app repositories are also a possibility, thanks to the Open Build Service (<http://openbuildservice.org>). And since MeeGo's community apps service is open source (<https://github.com/nemein/com_meego_packages>), all software needed for this (including an app store client app) already exists.

What is needed is a major distribution to make the first move on this.

<comment><USER3> You would still need to maintain and manage the core distro. The packages in their would update and break the systme, you'd have lvm issues and what not.

Any way, care to give links to more on maeom/meegos architecture?

<comment><USER6> You still package and build an application separately for each distro version. And then the community tests it before it goes to the stable apps repo. So broken packages (either by packaging, or by app not functioning properly) are unlikely to pass QA.

So if your package conflicts with something, either fix that issue or don't release for that distro versio.

<comment><USER7> Off-topic: Is active Meego Development still happening? I'm a QT developer and might be interested in contributing a little...

<comment><USER6> The MeeGo community effort continues at <http://merproject.org>

Used already as the base distro in the Spark tablet

</comment></comment></comment></comment></comment><comment><USER8> The Linux desktop is dead. Face it. Accept it.

How do I know this? Go to a developers' or tech conference, and what is the prevailing OS? 9/10 times these days, it's MacOS.

As much as Apple may be control freaks, they did desktop UNIX right and developers have flocked to them.

Meanwhile, the Linux desktop community is still having the same debates, the same difficulties it had back in the mid-90's. Dependency issues. Lack of compelling use case software; and that which does exist is versions behind current. Fragmentation.

The only areas in which the Linux desktop has moved forward is UI and user- oriented management, and Ubuntu deserves much of the credit for the latter.

Add to this the gradual movement away from the desktop paradigm to mobile. The desktop paradigm will still be around for several years (especially for creators--developers, media folks, etc), but the end-user is moving more and more towards smartphones and tablets for consumption. Extend those with external keyboards and monitors (think docks) for light creation work (documents, spreadsheets, etc), and you've the future.

Nope. The Linux desktop is dead.

<comment><USER9> _The Linux desktop is dead_

This is really premature because there are major flaws with the other options. Apple is a closed-down walled garden (and it's expensive), for example.

The Linux ecosystem is extremely diverse, so maybe somebody will come up with something that can compete well with these other flawed models.

For example, maybe Ingo Molnar's post will inspire people to take things in new directions.

 _The desktop paradigm will still be around for several years_

That's a ridiculous understatement. You can't do serious work on smartphones and tablets and that's not going to change until we're going around plugging them into projectors and keyboards, at which point they're just serving as desktops anyway.

</comment></comment><comment><USER10> I've been using Linux since 1993, and back then, the Linux OS and desktop were far superior to Windows 3.1.

Then Win 95 came out and that had a decent desktop. I remember when the KDE people started talking about a desktop for Unix and people didn't get it, but when we saw the beta it was like... Wow!

Then Red Hat Linux didn't like the license of KDE, so they had to create Gnome. As a result, rather than having one good Desktop, the average Linux has two half-baked desktops. This fork has wasted people's energy and been a distraction away from an excellent experience.

Another example of this is sound. I don't know how many incompatible sound APIs exist for Linux now, I know it's more than the fingers on one hand. The consequence of it all is that often sound doesn't work and unless you're a crazy enthusiast you might never get it to work.

I was a Linux zealot until 2003 or so when I had a job that had me using a Windows machine a lot, and by that point there was Win XP which was a huge improvement over Win 95.

I still use Linux on servers, but desktop Linux has largely disappeared from my life. Every so often I try to install it here or there, but I typically find the experience disappointing. I was a Fedora fan for a long time, but Fedora became increasingly finicky about where it would install. I switched to Ubuntu, but every installation ends up having some serious problem.

For instance, Ubuntu installed just fine on my PPC Mac Mini with the exception that the fan runs full speed all the time and the machine sounds like a vacuum cleaner.

Windows and Mac OS have been on a general trajectory of improvement -- sometimes there are changes you don't like, but the overall direction is good. Linux did, after years of struggle, get a stable multiprocessor kernel (2.6) but other than that I get the feeling Linux has been going backwards not forwards.

<comment><USER11> What you say used to be true, but does not appear to be any longer.

When was the last time we had useful improvements to the OS X user interface? 10.4 (2005) or 10.5 (2007), in my opinion. They've certainly improved under the hood, but the improvements to the UI have been mostly gimmicks like Expose.

When was the last time we had useful improvements to the Windows UI? That would be Windows Vista, 2006/2007. (W7 was basically just a stable version of Vista). Windows is certainly attempting to add improve the UI with Metro, so it's a 5 year timeframe to wait for improvements.

OTOH, in Linux land we've had KDE4, Gnome3 and Unity all land in that time period. Every 6 months we receive useful new improvements to our UI. Sure, the initial reception to KDE4, Gnome3 and Unity were all negative, but the haters are always the loudest. I haven't tried Gnome 3, but Unity 12.04 and KDE 4.8 are both really nice, much better than the OS X or Windows 7 UIs, in my opinion.

And it's not just the UI. It takes about 10 seconds for my computer to leave the BIOS and have both Firefox & Emacs open in Ubuntu. It takes the same machine over a minute to have Steam open in Windows.

<comment><USER8> There's just one problem with your post: you're thinking like a technologist, and not like an end-user.

End-users don't want to have to learn an entirely new UI (read, a different way of doing things; or, "Where's my Start button? Everything I know how to do is under that.") every couple of years. Not because they're (all) dumb, stupid, or lazy.

It's because end-users view a computer as a tool to do what they need/want to do--quickly and efficiently. Anything that distracts from that (like having to re-learn where everything is, and how to do the task they've done the same way for several years) is a negative and annoyance.

Unfortunately, the technology community has forgotten that.

<comment><USER9> _There's just one problem with your post: you're thinking like a technologist, and not like an end-user._

Well, a lot of people who use and hack on Linux distros aren't targeting the "end-user," they're targeting the technologist. So that mindset is not necessarily a problem.

<comment><USER12> If we're going in that direction, then everyone's participating in a different conversation. The original conversation was not whether or not this is a non- problem because end-users have issues. The original conversation was why hasn't Linux been adopted by end-users at the same rate as other OS's, if it's superior in so many ways.

</comment></comment></comment></comment></comment><comment><USER13> The author is right mostly, the problem is friction and market dynamics. Adding software in a given linux distro is too nerdy. If you don't have an "app store" like gui, you've already lost most users. Command line = friction for most users, even a lot of developers who grew up with windows.

As a linux nerd, I'm fine with command line + synaptic, but look at how well people have used the iTunes store, Amazon store, Google Play, etc... All of those have much less friction to find and download the right software than most linux distro's have. Ubuntu's market is close but...

WHERE IS THE NON FREE SOFTWARE?!!

If linux wants to do well for humans, paid, proprietary software NEEDS to exist on the platform. Ubuntu Software Center comes close, but it still kind of sucks.

Also, as a dev, it wasn't until VERY recently that you could even sign up to publish an app that was commercial in nature. It is hard to build a real marketplace when you're asking developers to give away all their work for free so that you can sell more operating systems (or support contracts) without the software dev seeing a dime.

As a software developer I can't feed my kids with free downloads on an open source operating system used by people who don't like paying for software.

Make it easy for devs to build software that people will pay for, then get operating system users who will buy that software for real money and you'll have fixed the Linux Desktop problem.

<comment><USER14> App stores can suck too, think Blackberry. You don't have to resort to the command line to install packages. Synaptic just needs a little freshen up that's all. I far prefer it to Ubuntu's software centre. A load of crap icons and screenshots just feel like clutter, and don't tell me anything.

</comment></comment><comment><USER15> Ten years ago I was trying to persuade people that two things were very important for Linux to succeed in the desktop:

1) Distribution of software as a cross-distribution package that just has everything it needs inside a directory, libs and so forth. If you said this N years ago you were an asshole because "duplication of file blabla" and so forth. The typical example was "an user should simply go to some web site of some application, download a file, and click on it to execute the program".

2) Device drivers with a well specified interface between the OS and the hardware, so that different versions of the kernel could use the same driver without issues.

People complained a lot with technical arguments, about why a different approach is better than "1" or "2" from some kind of nerd metric. So the reality for me is that Linux does not succeed in the desktop because it is "run" by people with a square-shaped engineering mind. There is no fix for this.

</comment><comment><USER16> Molnar's point about the _political_ and _procedural_ difficulties of adding new applications in the official repositories of most distributions is true (although this is changing -- witness Canonical's Ubuntu Software Center, PPAs, and "universe" repositories).

But his reasoning breaks down when he says the relative dearth of _commercial_ applications for the Linux Desktop is due to this issue. That's not true.

The main reason why OSX/iOS, Android, and Windows attract more _commercial_ developers is because those platforms have a much greater installed base!

<comment> muuh-gnu > The main reason why OSX/iOS, Android, and Windows attract more commercial > developers is because those platforms have a much greater installed base!

A few years ago, Linux had a bigger installed base than both iOS and Android. Both of them outran linux with ease.

<comment><USER17> Yeah, but they're in a brand new market on brand new devices. People who already have a proprietary PC OS aren't going to switch to Linux out of the blue, but they are going to buy a shiny smart phone.

So the two situations are really not comparable. I still think the main difference is that you have to install Linux yourself. It's not even that installing is _difficult_ \--it isn't!--it's that normal people don't even realize it's an option. Your average random laptop buyer who just spent $600 on a laptop from Staples would be able to use Linux perfectly well if that's what his laptop came with--I suspect some wouldn't even realize it wasn't just a different version of Windows. But since his laptop invariably came with Windows, that's what he's going to use, not for any reason but inertia.

<comment> muuh-gnu > but they're in a brand new market on brand new devices.

But they still had no problem starting with an ecosystem with zero apps. Now they have hundreds of thousands.

> I still think the main difference is that you have to install Linux > yourself.

Over the years, I've had several people, whom I talked into checking out Linux, give it up and go back to Windows because they refused to accept that they have to upgrade the whole distribution just to be able to install new versions of single apps. Did you ever try to explain a Windows user what a "backport" is, and whats it good for, and why there are none on Windows and why he can he can install whatever app and whatever version of an app he wants on Windows, but cant on Linux?

> Your average random laptop buyer who just spent $600 on a laptop from > Staples would be able to use Linux perfectly well if that's what his laptop > came with

For 6 months, then he wouldnt be able any more to update his apps.

</comment></comment></comment></comment><comment><USER18> I am running on linux desktop for already 5 years together with 50 friends, peers etc. It does not quite seem write to compare 90 cent mobile applications, which are 'mostly' few bunch of screens interfaced to a service otherwise given by a web site or simple 80s area arcade games, to packages in a linux distro. the author is totally making a terrible mistake here. mobile apps lack in size, complexity and who said they are great? they are mostly consumables which perish in few days or months (I exclude some ).

Ubuntu is already trying to be more flexible with software center and applications, however open source is not single walled garden which can adhere to tight monotonous architectures found in mobile.

In an linux distro the apps are diverse, and programmed in multitude ways by all possible programming languages (from python to lisp to C) and environments. That is reality and life, and what must be done must be done by being aware of that fact. and No, no one can force the broad, diverse open source world to a tight control a la Apple.

<comment><USER19> >they are mostly consumables which perish in few days or months (I exclude some utitities).

This is simply false, there are plenty of complex apps with varying degrees of usefulness but they certanly don't reduce to 80's game clones and few screen apps. And even if it was true it's not a result of anything intrinsic to the app model. Also "tight control a la Apple" indicates that you missed his point.

How many times did you do make and sudo installed shit on your system to get basic app that should for all intents and purposes be walled of in a sandbox ? Even without sudo why should install script have access to my personal files without explicit permissions ? Did you run in to a situation where you wanted to install the latest version of an app for your system but it wasn't in your distro repo so you decided to build it only to find out that your repo GTK+ library was out of date and your options were rebuild all GTK+ packages or update the OS to alpha ? Even I gave up at that point - imagine the average user wanting to get the latest feature advertised on his favorite app site.

I use Linux desktop daily but it can be a hell and you need to know how to wrestle with the system, it's certainly not idiot proof - and it needs to be for mass adoption. But then again "mass adoption" (IMO) shouldn't even be considered a realistic goal, being useful to techies/developers and available on servers is a good objective too.

<comment><USER20> I agree that having to make and sudo install is essentially impossible for a common PC user, but how does the sandboxing have any impact in user adoption?

<comment><USER21> State is the big evil in software. Minimize shared state, and many, many problems go away.

Centralized package management with a web of specific versioned dependencies is a huge hairball of state as it is. And when installed applications poke around inside your system, it only takes one or two oversights here and there to mess up this state.

Sandboxing, where feasible, minimizes shared state; usually at the cost of other things, but with modern software and modern resource constraints, our ability to deal with complexity is usually the tightest constraint. Sandboxing reduces the probability that things will break horribly (e.g. installing one app, and finding you need to install a new version of a library, which in turn means you need to reinstall 100+ more apps, which may bring in a new desktop or some other abomination).

<comment><USER20> That has nothing to do with sandboxing: it's a matter of distributing the libraries with the package itself, either as .so files or as a big statically compiled binary, and using those instead. Nothing forces the developer to use the distro provided libraries.

And frankly, I think this is one of the things where you can't please everyone; personally, I rather have dependencies and know that a security fix in a library will fix all applications that use it than having to hope each developer releases an updated version, like on Windows.

<comment><USER21> That's true to the degree that the implementation of those libraries does not require other things from the rest of the system. If they are just libraries of code, attached to nothing, sure.

But when they need integration with things beyond that? That's when it breaks down. That's when you need interfacing libraries that adapt one version of a library's interface to the next version, and very careful API and ABI design. I see that there's very little reason to take that approach for open source everywhere, but that kind of environment is essential for the stability commercial development needs.

Static libraries aren't the answer. A careful API and ABI interface to the core system, with managed compatibility from release to release, is needed. This is hard work; incredible amounts of effort went into making Windows 95 work as smoothly as it does, and some of the best war stories from Raymond Chen's blog date from this effort.

Things like preserving bugs in the moral equivalent of malloc to accommodate software that used memory after freeing it. This very concept - <USER2> compatibility - is something that I see OSS community in general as being fairly hostile to, thinking that the software with the bug should be fixed, rather than making things work for the user. Of course the buggy software should be fixed; but making things work for the user is more important still.

<comment><USER11> Actually, your post is making me optimistic.

On Linux, the 4 most common API layers encountered by an application are:

1) system calls 2) standard (and not-so-standard) libraries 3) X11 4) d-bus

#1 is notoriously stable. Linus often posts quite a vehement response to anybody who proposes breaking #1.

#3 was for a long time, TOO stable, it wasn't taking advantage of new developments in hardware and design. The breakup of XFree86 freed that up.

#4 is relatively stable because it's a cross-distribution partnership. They're designed to be the same across multiple distributions which by necessity makes them stable.

The problem are for Linux is #2. Most standard libraries are actually very stable on the micro level. The problem is the vast area they expose: if a single backwards-incompatible change can break your app, it's a problem if there are a million things that can potentially change.

Windows & OS X applications "solve" this problem by shipping their libraries with their applications.

I think Linux has a potentially even better solution: simply allow multiple versions of applications and libraries to be installed simultaneously, a la rubygems & bundler. You'll get all the disk space savings of shared libraries at the point of initial install, which will slowly erode as users install new apps, upgrade some apps but not others. But who cares? Disk space is cheap, but more importantly, if the user cares he can do something about it, only upgrading applications when the whole application upgrades.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Igor's point about distros trying to "own" 20K packages is well-taken; it's simply not possible.

In my own life the 'solution' I have found is to use FreeBSD; I get a stable, well-maintained core with a sharp distinction between core, userland and third-party (the ports system).

I have found the ports system to be a lightweight, agile alternative to GNU/Linux package managers:

When you install FreeBSD you are left with a kernel, standard UNIX command- line utilities and everything you need to hammer the system into a finely- honed tool.

Right now, I'm using it exclusively on my servers because I'm willing to accept the trade-offs of Ubuntu (beta 12.04 on my dev box, XUbuntu 11.10 on my netbook) on the desktop; a little instability and fully-automated updates is OK in exchange for not having to fiddle with graphics drivers, sound, Flash, etc.

</comment><comment><USER23> I'm just an ordinary user, but I'd put my 2¢.

Nowadays, any developer can create a packages for his application (and any of its dependencies) and publish it in self-hosted repositories. Users can easily add such repository to their system's sources list and bureaucracy problem's over. Well, some developers are doing this already - the only thing that keeps the rest of them is either ignorance or complexity of the packaging process.

I believe there's no need for an Android market clone (which is yet another centralized repository). What users may need is just a directory, pointing to external repos. Ubuntu market seems somehow promising (at least I remember seeing some dialogs like "you need to enable this source to install that package").

Content duplication is not a problem. A real problem is keeping the system up- to-date when you _want_ to update some library, because of an important feature or bugfix. And it's nearly impossible with every application's bundling their own copy of that library, with some copies being actually incompatible forks (and a lot of copies being just different builds - think of different compiler versions - of exactly the same sources).

<comment><USER24> What you think is easy is actually not easy. Any time you've added one, two, three more steps to a problem after clicking the link in the browser you've already lost. Adding repositories? Already too late. Touching the command line? Sorry, as much as we love it, for most users it's already too late. Going into Aptitude or Synaptic and pasting in the repository URL? Yep. Too late.

This is all compounded by the fact that there is no app bundle. Mac OS X has the bundle and a terrific way to install it: Drag and drop it into the Applications folder, just like we did in the days of the Mac Classic and MacPaint. It hasn't changed. (Well, it did for a while, but thankfully they went back.)

If you say, "Well, that means you end up installing 5 different versions of the same library on the same system" - Who cares? Disk space isn't a priority any more, and from a developer standpoint it makes a lot more sense to target a dependency whose version number I know, instead of a dependency whose version only the package maintainers know for sure. I don't want to be forced to target v1.3 of a library if it's only been tested (by me) on v1.2. It makes for much better application stability for the developer to be in control of dependencies and not these package maintainers.

I want to ship a self-contained bundle of awesomeness, not a dysfunctional shard among ten thousand other shards.

<comment><USER23> > Adding repositories? Already too late. Touching the command line?

Nope. As simple as clicking a link with special URL scheme, like `apt+hXXp://archive.canonical.com?package=acroread?dist=feisty?section=commercial`

> This is all compounded by the fact that there is no app bundle.

I'm all for the bundles (which single-app repositories, actually, are!), but I want them to be non-monolithic (i.e. contain multiple separate packages).

I don't care about disk space — if I'm _that_ constrainted with disk space that's probably another story that'll probably never happen to most ordinary users, having terabytes of storage. But I certainly care about bugs, and if libXYZ 1.2 has a critical one, I want my system to be free of that version ASAP.

And I don't care that you've never tested your awesome app with 1.3 — it's better to be _possibly_ unstable than _certainly_ unstable or, far worse, vulnerable.

<comment><USER24> What makes package maintainers uniquely qualified to patch dependencies and upgrade them? Either we say Canonical or Red Hat hires the best possible people to watch over their package repositories or we say that a qualified application developer could do just as well. Either way we end up having to trust somebody.

Both package maintainers and developers have an interest make sure their programs don't introduce vulnerabilities into the system. Therefore if there's a serious problem with one of their dependencies vulnerability patching will happen either way.

The distribution maintainers should be in charge of maintaining a core set of low-level dependencies that are needed by many applications. Beyond that they should leave the dependency management to the application developers. Seriously. That would free up so many millions of man-hours of work for say, Canonical, that they could actually make the core system usable to the average user.

</comment></comment></comment></comment><comment><USER25> UNIX in general never transitioned well from single binary applications that could just be placed in /bin /usr/bin or /usr/local/bin as appropriate to multi-file applications that needed an array of libraries, resource files etc. That coupled with a file system layout that nobody could ever agree on made it a mess once UNIX moved outside the curated environments it was typically found in prior to Linux.

NextStep made a good stab at the problem with bundles (.app .service .framework etc) but once you moved outside of the abstraction layer you were right back into the mess. Most Linux distributions seem to want to emulate SunOS circa 1992 and any attempts to "improve" on the solution in drowned out by fundamentalism.

I actually though the author nailed it in the last paragraph of part 2 of his post. The free software movement needs to start looking forward and not try and emulate what worked 20 years ago. There is definitely potential for a brave organization that is willing to try and tackle the challenge.

</comment><comment><USER26> My impression is that the problem is more fundamental: a lot of open source and free software which finds its way onto linux is made by people who don't seem to care about the end-user experience. If it works for them, there is no need to improve it.

Not all open software projects are receptive to changes, improvements or bug reports from strangers so nothing is really resolved without forking by which adds its own complications.

Of course there is still good open source / free software. It's just hard to come by.

<comment><USER17> Even more proprietary software that doesn't make it to Linux is written by people who don't seem to care about the end-user experience. I've spent enough time battling horrible programs on both OS X and various versions of Windows to know that this isn't unique to open source software.

Of course, on the proprietary platforms, the _core_ programs--browsers, office, media...etc are all good. But that is true of Linux programs as well. And open source projects--even ones that are not terribly responsive--are still _more_ responsive than most proprietary programs.

</comment></comment><comment><USER20> So, how does the fact that any person or company can host their own packages or even full repositories that can be added _with a single click_ ¹ and are not dependent on hierarchical organizations fit in that?

GNU/Linux distros, at least APT based ones, are perfectly distributed if the person wants to.

¹ If you have apt-url installed, which Ubuntu has _by default_

<comment><USER27> I agree that distributed repositories are the way forward.

The only thing holding that back is the _atrocious_ user-interface. Debian urgently needs to fix that and push their apt-infrastructure out of the 1990s.

In short: /etc/apt/sources.list must die.

This is how it must work:

       apt-get install https://foobar.com/debian/squeeze/widget-1.0

A package installed like that must add itself automatically to a proverbial sources.list for future updates. Don't bother me with the housekeeping.

Then add central indexing ('apt-get install widget' is nicer), a web-of-trust ("1234 users have installed packages by this author"), package-signing looks about alright already (except: no, don't make me run gpg).

This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes.

And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work.

tldr; apt needs to absorb homebrew.

<comment><USER20> But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?

Provide a .deb from your website, use the install script to add your repository to the sources.list. There, the user doesn't have to know or care about that file. And this is all possible - no, easy - to do right now.

 _This is how it must work:_

I disagree, having to run apt-get is too cumbersome to a regular user. But a better way _already exists_ in the form of apt-url. Click a link, have the package downloaded and installed automatically.

 _This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes._

But my point is that most of the infrastructure (support for multiple repositories, one-click installation of third-party packages) already exists. That's why I don't agree that this is the problem with Linux.

 _And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work._

I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc.

<comment><USER27> _But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?_

You are right. My point was that I (the user) shouldn't need to know that a file by this name exists. Of course debian is free to maintain the bookkeeping in any way appropriate.

 _I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc._

People would check-in either the deb or the debian/ meta-files. The latter would be preferable, but the deb package-building process needs to be simplified for developers to consider participating.

The current deb building procedure is a trainwreck, which is in fact a related problem. Homebrew recipes and gentoo ebuilds are trivial in comparison, there's no reason the deb process needs to be as convoluted as it is.

</comment></comment></comment></comment><comment><USER28> I disagree. The author seems to forget the fact that packages are only a layer of added ease of installing new software. The act of installing new software from source or binaries distributed by the author is still as free as ever.

I admit that I do install about 90% of my programs as packages, but the problem of central authorities responsible for patching and distributing software and taking too long to do it isn't present in every distribution. I've used Arch Linux for years now, and it solves this problem by separating the packages into an 'official' channel of reliable maintainers testing and releasing new versions on the package system and a user repository where anyone can add packages.

To me, this seems like the optimal solution. Community-maintained packages can be promoted to official ones, from what I can see new versions are released from testing within days and if you're not satisfied with how others maintain the packages, building the packages from the newest versions yourself is almost as easy as installing binaries from the repository because anyone can use the build and packaging scripts used by the maintainers themselves.

</comment><comment><USER29> There are "core" linux distros, like Slackware. There are many attempts at autonomous apps distribution like zero-install and openpkg that mostly work, and probably would work fine with a reasonable effort backing them.

[1]: <http://0install.net/> [2]: <http://www.openpkg.org/>

Of course the problem is that the big distros (redhat, debian) can't be bothered to care.

<comment><USER30> And in fact, with their sysadmin focus, they explicitly are opposed to this method. If your goal isn't a desktop experience but rather protection from every adversary at all times, then only vetting a small core and letting people run various and sundry packages from third parties is flat-out irresponsible. But of course this is what desktop users want -- to run any software they like with no hoops to jump through or update schedules to keep on top of, so they will always be at odds.

</comment></comment><comment><USER31> Yes, I see the point being made in the original article. I tend to use LTS Ubuntu and conservative distributions (currently PUIAS) and so see a slower rate of change.

Another Hacker News thread is discussing the new release of Audacity.

<http://news.ycombinator.com/item?id=3714766>

and it occured to me that I would like to try to compile a _statically linked_ build of Audacity that could work on any version of GNU/Linux from Ubuntu 12.04 down to (say) CentOS 5.7. Just a big binary blob that I could copy and run.

How would I find out how to do this? I've compiled little things before (dwm window manager, qalculate)

</comment><comment><USER32> It really frustrates me that authors are not responsible for compiling and distributing their software, only then will we have software upgraded regularly and quickly.

<comment><USER33> which distribution should they compile and distribute (sigh) for? Not to mention basic problems like "should I integrate with GNOME, Unity, KDE or nothing at all?"

<comment><USER23> There are only 2 popular package formats: deb and rpm.

I don't have any experience with RPM, but to build a package for a reasonably big part of the Debian-based world, you have to set up a build system (pbuilder/cowbuilder) and tell it something like `for DIST in lenny squeeze wheezy sid lucid maverick natty oneiric pangolin do; git-buildpackage ...; done`

The problem is, to get it right one has to find and read _TONS_ of documentation.

<comment><USER34> It'd be a lot more popular if it was as easy as the Android apk export wizard.

My 2c: Improve the tools and the developers will follow.

</comment></comment></comment></comment><comment><USER35> This is basically why Ubuntu has PPAs and what they are trying to turn Software Center into right?

</comment><comment><USER36> I've been happily using the stable branch of Debian for about 4 years now. Whilst I agree bureaucracy and politics should be avoided where possible, it seems to me that handing everything off to a 3rd party to focus on the "core packages" harms overall system performance.

Time and again I hear people in the lab complain about all these bugs in their applications, running Debian I can honestly say I don't have this problem. Ofcourse, I don't have the latest software either, but for me that's the price I pay for a stable system.

</comment><comment><USER37> Most of the complaints here don't even have any suggestions, just a complaint that can be easily translated to "dependencies in software are hard to manage". Well, no shit. How about some interesting ideas around this from the "hackers"?

The ideas that are proposed are mostly things that have already been tried but have failed because of social/manpower reasons (they would take enormous amounts of effort and time from all involved for little benefit) or technical (they don't work)

A large percentage complain that the distro in question updates _too_ frequently, when there are clearly distros that cater to stability (they just aren't the "cool ones").

Some of the complaints are demanding some mythical OS that allows you to install it once, never have it update or change but still have access to all the newest software. That would be wonderful. No one has figured that out yet, not windows, not mac, not any *nix.

I know bitchy comments aren't helpful, or likely to be well received, but there must be some other people of my ilk still on HN. Now that it's Product Guy News, where should I be going? Where is this story posted with people actually talking about interesting ways to improve things who actually understand the problem and could be called hackers without the technically skilled people laughing?

</comment><comment><USER38> Part 2, where he discusses his solutions, is more enlightening I think.

He's dead-on about the impassable problem of package updates affecting other packages. Having everything sandboxed with a general permissions system for directories instead of per-file is also better (this is how MacOS wanted to work before OS X). A free and open mesh network with reputation-based security is also the future.

But hey, linux is wide open, if these are the changes that are needed, we will see them.

</comment><comment><USER39> Isn't the problem that the distributions are downstream to the apps and libraries they install ?

Quoting android and ios ecosystem is well and good, but in those ecosystems the os comes first and the apps are developed downstream. You simply cant have that in a linux eco system.

</comment><comment><USER40> Why do linux distros keep trying to recreate the gaudy, confusing experiences of the proprietary systems? I want my drivers to work, and a window manager that wraps the file-system - allows interaction with the files. In an ideal world, someone would restructure the four bin directories so that system stuff was in one area, and user stuff was somewhere else so we could easily open what we want by navigating the tree.

</comment><comment><USER41> Just for another POV -- I love the fact that I can apt-get a version of practically any FOSS project of note, and within a minute or two, I have something that works with the rest of my system. If I need bleeding-edge, I go to the project page and download a later binary or source, but 90% of the time that's not necessary.

For me, it's a perfect combination of a vetted ecosystem (ok, somewhat closed but closed in the way I like -- no crapware, all legit source distros and mostly mature projects) with the ability to go outside that system at any time, at my own risk.

Anyone can set up a repository to add to/compete with Canonical's, and of course they do. So with my willow garage repo's, I can keep up with their concept of what's stable, etc. It works nearly perfectly, IMSHO.

</comment><comment><USER42> Isn't the real issue simply that the desktop distributors simply lack the manpower required to out together a stable desktop release, party due to the massive fragmentation?

I assume MS and Apple have huge teams dedicated simply to making sure that all of this software works together nicely.

If there was a desktop distro that cost $100 a throw and that money was re- invested in testing the desktop platform more thoroughly and making it past and future proof that this would solve many problems?

</comment><comment><USER43> Sounds like he wants a distro agnostic Ports system, one that hides the dirty work of watching compile time crap fly across the screen and just gives the user a suitable package for their distro.

Either that or he's essentially suggesting we move to static compiled packages, which while tremendously inefficient from a space and security standpoint would alleviate at least some of the headaches of trying to do cross distro binary offerings.

</comment><comment><USER44> Maybe Android will conquer the desktop then?

All it needs is mouse and keyboard support in the interface and higher- resolution apps, which will come for tablets anyway.

<comment><USER6> Android has pretty good mouse and keyboard support already. Try one of the Asus Transformers in laptop mode, for instance. Keyboard shortcuts, mouse cursor, two-finger scrolling, all works as you would expect on a desktop.

High-resolution apps are still somewhat lacking because the larger tablets haven't sold that well, but I hope this will improve.

</comment></comment><comment><USER45> Good point. But most of these apps are written, because they can make money for the author. There just isn't a large enough user base in Desktop Linux to make that money, and hence much less people willing to invest the time to write apps. And the much smaller userbase is split up between Gnome and KDE and now Unity and Xfce and so on. So there is even less incentive to write apps.

<comment><USER17> A program that works in KDE will work in Gnome and Unity and Xfce, so that divide is not strictly relevant. In KDE, at the very least, even GTk programs look very good. And, moreover, those programs would also work on Windows and OS X.

</comment></comment><comment><USER46> Linux is being used by more developers that I see than ever and even regular people are finding out about it and trying it out.

</comment><comment><USER47> The author mostly talk about maintaining packages. Some people say that it is the missing games and other desktop applications. However, we all know that Linux is best OS for development. It has best set of libraries, languages and utilities. Yet, why there not many cool Desktop applications?

I believe the answer is, Linux doesn't have an IDE for Desktop development. Look at windows, they have .net Platform and IDE, Look at Mac, they have Xcode and Android uses eclipse for IDE.

Most of the application developers want and IDE, which is what is lacking in Linux. I hope someone makes an IDE for Linux desktop development.

<comment><USER48> QT Creator for Cross-platform. KDevelop for KDE focused stuff. Not sure what for GNome.

What is wrong with the above?

<comment><USER47> I didn't know about QT Creator, it looks really good for application development. A lot of people are using Ubuntu for their desktop, including me and my friends. But, Ubuntu's landing page doesn't have a tab called "develop" for leading users to develop applications for ubuntu. So, My impression is linux is a great OS with libraries and frameworks necessary for system development. But, it didn't had the tools to build applications. But, apparently it does. Linux distributions should encourage users to write applications. The best way to do this would be having the information right on their landing page.

</comment></comment></comment><comment><USER49> Part II of Ingo Molnar's blog post: <http://news.ycombinator.com/item?id=3719719>

</comment><comment><USER50> I have to wonder if people's expectations are just a little to high for something that is free. I think a large amount of people complaining about Linux did not use it when it really really sucked (back when Slackware and RedHat were the only options).

Linux is a hackers operating system. When people try to make it into a desktop operating system it starts to suck (Gnome 3).

</comment><comment><USER51> Honestly, Linux is a lot like the tiptronic setting on my cars gearbox. I have thought it's a cool feature and I'm glad it's there but really... I never use it 'cos it's kind of fiddly and dumb.

</comment><comment><USER52> what I prefer in this posts is the interesting discussion coming with the article. It seems attention whores and trolls have not yet reached g+, it looks pretty sane for now.

mode religious:on please g+ try somehow to make a good karma system to keep the NSR low.</comment>


The Trash Museum - <AUTHOR> http://www.nytimes.com/slideshow/2012/07/24/nyregion/20120724appraisal.html?ref=nyregion

<comment><AUTHOR> If WALL-E had a real-life inspiration, this man could easily have been it</comment>


Allow me to vent! - <AUTHOR>

Aargh.  Javascript.  DOM model.  Internet Explorer!
Having spent all day writing Javascript for a nice reporting application I came to the dreaded moment when I started cross-browser testing.  It's not that everything was broken, it's just that IE debugging Javascript is death by a thousand cuts, or a thousand little incompatibilities.
Aargh! <comment><USER2> Unrelated, but sort of not:

I'm in the process of setting up some Windows servers. I haven't really touched Windows as an OS in a number of years (linux and OS X mostly). I can't believe how horrible the interaction is, ESPECIALLY with IE. Holy crap, quit with all the popups about adding sites or whatever. It took me a dozen clicks after I typed in www.firefox.com just to get the page to load.

I'm amazed that people actually use IE, it's user experience seems like an experiment in cyber-torture.

<comment><USER3> IE7 loads up twice as fast as Firefox, has almost universal compatibility with web sites, and isn't to my knowledge lacking any significant functionality that would compel a switch to Firefox (including blocking popups).

<comment><USER2> Loads up what twice as fast? Pages or the app itself? I could care less about app loading times, I hardly ever reboot anything, so once I launch FF, it stays running.

IE7 now has popup blocking, but it came years behind FF.

Of course, I also use Windows as little as possible, so IE isn't an option in most cases. And where it is an option, I prefer FF for the extensions anyway.

</comment></comment></comment><comment><USER3> Microsoft's Visual Studio doesn't do a horrible job of IE debugging. Just download the web dev Express version (free) and turn on script debugging in your Advanced Options.

<comment><AUTHOR> Thanks. I'll do that.

John.

</comment></comment><comment><USER4> I know the feeling. However, sometimes this can be largely avoided by using an already tested javascript library such as the yui tools or jquery as base. I'm not sure if they're pertinent to what your doing, but when they are it sure speeds these things up.

<comment><AUTHOR> This was a pretty heavy prototype/scriptaculous based application. I'm pretty familiar with the YUI stuff, but have never used jQuery. How does it compare to prototype?

John.

</comment></comment><comment><USER5> Firebug Lite might come in handy. I am strongly considering only supporting Firefox for the next application I build out of protest for IE's quirks.

</comment><comment><USER6> My recent issue with IE6 (not IE7) is that if you make a checkbox and then set it, and then insert it into the page, it becomes unchecked, so you can't easily pass around nodes.

This was IE6 on Windows ME, understandably frustrating after Firefox 2/Safari on OS X.

</comment><comment><USER7> I used to get frustrated too, until I switched to Flex!

<comment><USER8> You know, I love that rich client, cross-platform stuff. But heck, are users going to tolerate those load times?

</comment></comment><comment><USER8> Ah yes. Welcome to the party, dude.

What I did was start with IE, make it work, then "fix" it for FF, Opera, etc. Somehow that's less fretful than the other way around.

Cross-browser DOM programming will drive you to a good rant, for sure.</comment>


My father had one job, I've had six, my kids will have six at the same time - <AUTHOR> http://www.theguardian.com/society/2015/nov/29/future-of-work-gig-sharing-economy-juggling-jobs <comment><USER2> If you have in-demand skills then maybe the 'gig' economy can be a nice place to be: money and flexibility can create quite a nice lifestyle, if some comments I read on HN are to be believed.

But for those not in the top-layer its going to be "welcome to the precariat" [1]. Constant hustling, unpredictable income and housing, moving-on a lot, fewer social ties. For those at the bottom it's zero-hour contracts driving for Uber and stacking shelves at Amazon fulfilment centres.

Traditional full-time jobs provide a lot of the security necessary for long- term commitments like raising children, educating them properly (so that they in turn have sell-able skills), and engaging/participating in society. When almost everyone is chasing the next contract to pay the rent, the result can be a hollowed-out society where we all end-up poorer.

[1] [https://en.wikipedia.org/wiki/Precariat](https://en.wikipedia.org/wiki/Precariat)

<comment><USER3> I often get the feeling that proponents of the gig economy underestimate just how transient their "in-demand skills" really are. A person's in-demand skills can only take them so far before someone else comes along with equal (or even better skills) and undercuts the "top-layer". At which point, instead of having the time to acquire new skills, the individual instead needs to devote their time to the "constant hustle" of finding the next gig before their reserves are depleted.

</comment></comment><comment><USER4> One problem I can see in all this is that the trust networks that the sharing economy is built on are all (currently) privately owned and exploited, and network effects mean that it is very difficult for any competitor to get established in the same space because they have to establish their own competitor trust network. As a result the tendency will be for there to be a winner-takes-all outcome creating monopolies around the trust network in any particular vertical. See Facebook (network of trust around friendship), Uber (network of trust around giving/receiving transportation), Ebay (buying/selling goods), AirBnB (giving/receiving accommodation), Twitter (trusted sources of interesting opinions) etc. The only competitive strategy that seems to be working at the moment is having a vertical that is sufficiently different from the incumbent that you can attract existing users of the incumbent's network to use yours in parallel.

I doubt this is an outcome that governments and society in general will find acceptable when they start to recognise the pattern. Instead I wouldn't be surprised if the second phase of this economy involves government regulation of the trust networks, with them being extracted into some kind of trust infrastructure on which a number of competitor service providers are allowed to operate, or at least opened up so the trust network data has to be part of the public commons. At the moment the trust networks are (rightly) seen by the companies as being their most important asset - I think we'll eventually realise that, in the sharing economy, trust is _so_ important that it cannot be privately owned.

<comment><USER5> >The only competitive strategy that seems to be working at the moment is having a vertical that is sufficiently different from the incumbent that you can attract existing users of the incumbent's network to use yours in parallel.

How is this any different than Coke building up a trusted brand over 100 years? If you want to compete in the drinks market, you need to find a different vertical (sports, energy, fruit, health, etc.) and build up your own trusted brand.

I think we'll see the government slowly coming around to endorse/oversee/standardize digital trust networks as they always have through the FTC, FDA, FCC, etc. They've already started with Title II of HIPAA in an attempt to regulate how data flows in the healthcare system so that patients can trust healthcare providers.

But do we really need to oversee/nationalize a social network/content aggregator such as Linkedin or Facebook?

<comment><USER6>
      How is this any different than Coke building up a trusted brand over 100 years?

Well, I can always quaff a Pepsi, quite irrespective of what my peers chose to drink.

It doesn't work quite as well to use a different, say, social media platform, when all my friends are on Facebook.

<comment><USER7> Not necessarily. Pepsi and Coke have both built quite legal relationships with a number of institutions like universities and fast food chains with the agreement that competitor products are not served. My university was a "pepsi campus", you couldn't buy coke products anywhere on campus. This is why people have to ask "do you serve coke or pepsi?" at restaurants. Of course this has far fewer effects that social network tie-ins, but its not a new idea.

<comment><USER8> "This is why people have to ask "do you serve coke or pepsi?" at restaurants."

OT, but this is why news anchors have to say "the obesity rate in the US has risen to its highest level ever, scientists reported today."

<comment><USER9> Why? Because people drink soda at restaurants?

</comment></comment></comment></comment></comment></comment><comment><USER10> Yeah, I feel in general it develops in that way. More flexibility, less specialization. But I don't think it's really good though.

If you have a core set of skills and tasks you can often work very efficient. You know who to talk to, you know what to do, and if you spend time optimizing your work process after some time your daily life also is not too stressful. But if you always switch and hunt the opportunities you don't know much about anything. You always have to continue hunting.

But on the positive side I think it will be an option, at least in a foreseable future. Being flexible also means you cna say no to an opportunity if it is too far away from what you are usually doing. Of course that also requires more discipline than in the past.

Concerning money I think it depends on your talent/skills/education if it goes up or down. Talent becomes more rare when people do more different tasks (e.g. the "full stack devopser" can only know a little about web development, because there are so many other things he needs to know). And higher flexibility for employees means that companies have a harder time to keep talent. Therefore pay must go up for talent. But someone who barely gets by doing one job now has an even harder time doing 6 jobs at the same time, and he has a harder time to hide due to more responsibility on his side, and last but not least more flexibility also means companies don't need to keep you. Below the tipping point money goes down.

If one likes that or not probably depends on if oneself is above or below that tipping point. I can understand both sides here. No reason to discuss just the negative side.

</comment><comment><USER11> Capitalism is about the flow of capital. Most people don't have capital, so they have to trade their labor for a small amount with people that do have capital, who are only trading it to get more capital.

Articles like this assume that everything will change - except how capital works.

Bitcoin. Crowdfunding. Distributed banking. Mass market barter transactions.

I can't help but think that centralized stores of capital (i.e. the top layer, the rich, the capitalist, etc etc) are naturally going to become obsolete.

Unless, of course, they're kept alive by force.

<comment><USER12> This is where "r > g" and Picketty's work is relevant. The rate of return on capital matters. Centralised capital earning a return will always pull ahead of small-scale capital unless there's enough regulatory and other handicapping to the advantage of the small capital investment.

Can decentralised capital get a better rate of return than centralised capital? If so, centralised capital can just invest in it. If not, you'll end up paying your decentralised returns back and more in rent. Property is the ultimate centralised store of capital.

<comment><USER11> _If not, you 'll end up paying your decentralised returns back and more in rent. Property is the ultimate centralised store of capital._

I think this would assume that decentralized investments won't be able to afford autonomous, off-the-grid living arrangements. There's still a whole lot more land out there than we need. And it wouldn't need to support everyone, just enough so that there's an alternative to keep rents from skyrocketing.

Anything else you pay for can be decentralized, as the article demonstrates.

<comment><USER12> _There 's still a whole lot more land out there than we need_

You can't be serious - there isn't any _unowned_ land out there. Certainly not in the western world. Sure, in the Americas you can squat on government land for a while and hope nobody notices, but that involves being miles away from anywhere and if you're off the grid it seriously hampers your earning potential.

In the UK there is simply nowhere you can do this.

 _Anything else you pay for can be decentralized_

Microchip fabs?

<comment><USER11> _You can 't be serious - there isn't any unowned land out there._

You can buy land for less than $2,000 per acre in just about every inland state in the US. A cursory glance at Zillow shows that even Rhode Island has sub-$100k/acre available[1].

 _But that involves being miles away from anywhere and if you 're off the grid it seriously hampers your earning potential._

I'll concede that we're not there yet, but technology makes off-the-grid living and working more feasible all the time.

 _Microchip fabs?_

You mean like Intel? A company with 1800 owners?[2]

But without getting to boiled down in the minutia, my problem with Picketty is that there's no reason that the "r" in "r > g" couldn't be distributed using crowd-funding and decentralized currencies (and whatever _their_ successors might be) by the natural flow of capital, rather than relying on the coercive methods Picketty suggests.

[1][http://www.zillow.com/homes/for_sale/RI/land_type/50_rid/2-_...](http://www.zillow.com/homes/for_sale/RI/land_type/50_rid/2-_beds/0-540484_price/0-2000_mp/priced_sort/42.172564,-69.893646,41.026535,-72.557831_rect/8_zm/0_mmm/) [2][http://www.nasdaq.com/symbol/intc/ownership- summary](http://www.nasdaq.com/symbol/intc/ownership-summary)

</comment></comment></comment></comment></comment><comment><USER13> Maybe 'a job' is something that fitted a particular phase of our civilisation development and it just will fade away? A hunter gatherer (I bring this as my example - because as a species we spent most of our time in that phase) would do many things - but we would not call them jobs.

<comment><USER14> _A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects._ \-- Robert Heinlein

<comment><USER15> Said by a character that lived to be 2000 years old :)

</comment></comment></comment><comment><USER16> I believe that "spreading yourself too thin" is a real thing, and a real disadvantage. In a theoretical world, you could have a specific specialization that you used in isolation for many different jobs simultaneously, but in reality, a "job" is about so much more than one individual skill. There is onboarding, learning the people and environment and tools and product that you work on, and a variety of other peripheral matters that require much of your time and learning curve before you get to apply the skill you've been hired to perform. And thus you end up with a lot of time spent on things that wouldn't be an issue if you concentrated on one job at a time for a decent period of time.

</comment><comment><USER17> Personal anecdote: my dad used to work in a coal mine during the day, then drove a delivery truck in the evening, then during the weekend he worked at a local cafeteria, selling ice cream. He always thought I was being lazy not doing anything after coming home from my 9-5 job, and not having a second job on the weekend was almost sacrilegious. My point is that some people don't see the world the way this article describes them :P

</comment><comment><USER18> Looking at a lot of job ads they want 5 developers for one job: sys admin, dba, software dev, ui, design...

<comment><USER19> Don't be scared of _secondary_ requirements in ads as most often they don't require expertise in the mentioned area. During job interviews, "database specialist" "becomes" someone, who can write simple queries, "a web designer" \- someone who can tinker CSS, "web development" \- update Wordpress page etc.

<comment><USER18> I'm down with that. It just annoys me that managers or often agents expect you to be an expert. For instance i know oracle well and sql and pl/sql but i can also do some java, C, python, DBA, web development etc. My next role is at a startup and coming in as a data guy who will pick up some web services and javascript work seems totally acceptable.

</comment></comment></comment><comment><USER20> The statement "My father had one job in his lifetime, I will have six jobs in my lifetime, and my children will have six jobs at the same time." makes a pithy statement but is generally not true.

My father had about 6 jobs in his working life. Looking at my uncles they varied in the number of jobs but none of them had just one, over a working life of more than 40 years each. Thinking wider still, I cannot think of a single person in my parents generation that had just one job.

It might be that people average more jobs today than they did in the past. Maybe you can project that forward and guess that a future generation will average more. But to say 6 concurrently is wild speculation and hard for me to take seriously.

There is no reason to think our children will have many concurrent jobs. Certainly no more than people do today.

</comment><comment><USER21> +1 for The Guardian article and this discussion thread. I see the automation and replacement of jobs as one of the central problems.

I am mostly retired now so I spend more time mentoring (mostly) young people on CS tech, job market, choosing a career path, etc. Two common lines of dialog are what tech they have a passion for and the other is what tech is least likely to be automated. I may be optimistic in that I hope that a life process/system of continuous education and keeping in mind what types of work help society the most will see the younger generations through some 'interesting' times.

</comment><comment><USER22> > it seems strange to me that we would always recommend to companies that > their revenue streams are diverse, yet for individuals, the smallest and > most fragile economic unit, we say: you must only do one thing all your > life. What a crazy way to live; 87% of people in full-time employment are > not passionate about what they do. When I look at this new way of work, I > think of it as opt-in. It gives people economic agency, it puts them in > charge. And it gives them flexibility. People love those things.

I don't think people love these things as much as they love security, at least in the long term.

Every generation goes through this. Journalists act like Millennials are special people who won't be held to a 9-to-5 job like everyone before them, but they've made the same mistake as journalists who covered previous generations. Before these "gig economy" Millennials, we had "hippie" Baby Boomers and "slacker" Gen-Xers.

Young people of every generation are always going to say they don't want to live a traditional life like their parents, that they're going to chase their dreams and be genuinely different, and they join whatever the latest counterculture is. But, ultimately, they come back.

The hippies of the '60s and '70s became the yuppies of the '80s and the soccer moms of the '90s. Why? They want that sweet, sweet security. A boring job with a steady paycheck and loads of benefits means you don't have to worry about anything, as long as you come to work every day and don't spectacularly fuck up at your job. If you're planning to start a family, then you need the stability for your kids. If you're not, then the stability helps fund your life so you can spend the weekend enjoying your hobbies instead of worrying where your next meal is coming from.

Mark my words, in a decade the "gig economy" rumspringa will be over, and most of those people who chose to bounce from gig to gig for "flexibility" will be working in cube farms so their kids can have health insurance and go to good schools (and those of us without kids will be doing the same thing so we can indulge in expensive hobbies on evenings and weekends).

Oh, of course there will be holdouts, just like there are still hippies who live on communes well into their 60s, but by and large the gig economy will fade away once most of the original participants are out of their 20s, and pop culture will treat the "aging Millenial hipster" as a joke just like the "aging hippie" is treated now. And, of course, we'll see the beginnings of the next rumspringa as the next generation of young people decide they don't want to be like their parents... until they do.

<comment><USER23> Let's hope the "gig economy" people will actually be able to get a safe cubicle job in a decade. To me it looks like this option is systematically being eroded. Pensions are gone and I think steady employment for good salary will slowly go away too. And the node.js hotshots who think there will always be high paying jobs for coders like them should have gone through 2000. The fall can be quick and deep.

</comment></comment><comment><USER24> Strange that BlahBlah is made to seem so hot when ZimRide had to convert to Lyft to make any headway. I wonder if ZimRide overstepped their transition, or if BlahBlah executed better, or if Lyft is simply a richer pot.

What is interesting is that Lyft chases the taxis and BlahBlah chases the trains, or the other way around, depending on your loyalties.

Still, as the old adage goes, lots of people do have the same ideas around the same time. Winners are much more unique than that.

</comment><comment><USER25> I wonder what the last human will think once s/he becomes automated out of existence.

</comment><comment><USER26> And their kids will have 36.

<comment> guard-of-terra Or they won't have kids.

</comment></comment><comment><USER27> It is more likely your kids will have no job.

<comment><USER28> That would be in a perfect world..

<comment><USER27> Assuming we have some sort of base income I agree.

<comment><USER29> Base income does not come out of nothing though. You need state income, which depends on taxation, which depends on people working and consuming.

<comment><USER30> Unless the state owns the means of production.

What if the future is red?

<comment><USER31> red doesn't sell well in the USA. We'll have full communism but we'll market it as something else. Probably still calling it the "free market capitalism". That's what we inaccurately call our current system and nobody blinks.

Most likely it'll roll out like public libraries / utilities. I already drive on government owned streets kept safe by government paid cops and clean by government paid trash pickup to visit the government owned library to use the government owned photocopier when I need to do legacy media stuff. Not a huge extension of the concept at the library to use the government owned 3d printer to make stuff or the government owned protein sequencer to make me soylent- tier food, maybe in 30 years.

<comment><USER32> All of those govt paid employees are paid by you... their employer.

Not the govt.

The govt owns nothing nor employees anyone.

<comment><USER33> The government owns things and employs people as much as any corporation does, and as much as the government exists at all.

<comment><USER32> The govt is a structure which answers to the people and is supposedly for the betterment of the people. The government exists only because you consent to be governed. At any given moment you can revoke that consent. This govt hasnt been looking out for the peoples interests in a long time.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


KeePassX is alive and 2.0 is here - <AUTHOR> https://www.keepassx.org/news/2015/12/533 <comment><USER2> It's very disappointing not to see any sync options, or indeed support for plugins which could add such functionality :(

<comment><USER3> Save your database on dropbox/onedrive/google drive/etc. and you're done.

</comment></comment><comment><USER4> Any details on when the update will reach the main repos?</comment>


Facebook bans health and conspiracy site Natural News - <AUTHOR> https://arstechnica.com/science/2019/06/natural-news-hawker-of-vitamins-and-far-right-conspiracies-banned-from-facebook/ <comment><USER2> Good move, sites like that kill and injure thousand of people every year and they also rob them by sales of worthless meds with zero active ingredients

<comment><USER3> It will never cease to astonish me this lately-fashionable propensity to praise the censorship of information that you do not like.

Do you have any information to back up your assertion that "sites like that kill and injure thousand of people every year"? Or did you just fabricate the claim out of nothing because you wanted to contribute a hyperbolic verse in support of righthink?

<comment><USER4> This isn't censorship and it isn't information. Information is something that is true. These are lies that hurt people that a public company doesn't want to broadcast.

<comment><USER2> +1 Yes, like cockroaches - they hide from the light.</comment></comment></comment></comment>


java OOP help  - <AUTHOR>

Hi, am a Java beginner but it seems OOP  is blocking my way. Any help will save me. Thanks in advance <comment><USER2> Here's a reasonable conceptual starting point: [http://inventwithpython.com/blog/2014/12/02/why-is-object- or...](http://inventwithpython.com/blog/2014/12/02/why-is-object-oriented- programming-useful-with-an-role-playing-game-example/)

For the Java language itself, I'd recommend: [http://www.amazon.com/Java-In- Nutshell-5th-Edition/dp/059600...](http://www.amazon.com/Java-In-Nutshell-5th- Edition/dp/0596007736)</comment>


GNU/Linux Smartphone Librem 5 Evergreen Update: Mold and Milestones - <AUTHOR> https://puri.sm/posts/librem-5-evergreen-update-mold-and-milestones/ <comment><AUTHOR> If you want to compare the performance of Librem 5 with the cheaper Pinephone, watch these videos: [https://social.librem.one/@dos/104767475144787918](https://social.librem.one/@dos/104767475144787918).

Also, here is a detailed comparison of the phones: [https://forums.puri.sm/t/comparing-specs-of-upcoming- linux-p...](https://forums.puri.sm/t/comparing-specs-of-upcoming-linux- phones/6827)

<comment><USER2> I really respect Sebastian. He has very deep technical knowledge and hangs out on several Pinephone channels and offers helps on them. This is in spite of the fact that the Pinephone is more or less a competing product and I doubt he gets paid to do so.

</comment></comment><comment><USER3> I ordered a Pinephone. When it goes tits up in a few years I just may get a Librem. Both of these projects deserve your support, and I'm glad there's competition in the Linux phone space to keep everybody honest and innovating.

<comment><USER4> That's the approach I might consider. The Librem is out of my reach for now, and I just wanted to explore a mobile platform running a true operating system that is not a toy with added spyware, so the PinePhone is enough for me. In my opinion Pine64 did the right thing in solving the harder problem first (trustworthiness). Thanks for the sales of the PinePhone they hopefully will be able to make a better performing model in the future. If say I buy a PinePhone as personal gift for Xmas, then 2 years from now they introduce a new model that makes my model obsolete, I wouldn't complain at all because it would still do what it should do. The Librem is on another planet feature wise, which is expected from a device costing like 5 times more. But do I need that power? Well, I find really annoying doing anything on small screens, so I always take with me the laptop; all that power in a phone would be wasted since all I could ask to a privacy focused phone is to prevent my voice comms to be intercepted (from within the phone, of course LEOs have full access to comms), my contacts, files, photos and videos, music etc. to be copied; all things a 150-200 € open phone can do as well. But yeah, should I have the resources, I'd like to contribute both projects; they deserve that.

<comment><AUTHOR> > But do I need that power?

You can use these phones as desktops with connected display and keyboard. You can in principle run any desktop software (they call it "convergence"). Of course you need that power.

</comment></comment></comment><comment><USER5> I'm glad they again mentioned the RYF certification. It's the single most important thing which gives me genuine hope about this phone.

As far as I know, _no other phone_ is slated to have it.

<comment><USER6> I'd probably buy it if it got it, but I'm not holding my breath, given all the bad accounts I've read about the company:

[https://jaylittle.com/post/view/2019/10/the-sad-saga-of- puri...](https://jaylittle.com/post/view/2019/10/the-sad-saga-of-purism-and- the-librem-5-part-1)

<comment><USER2> For the record, when the librem 5 birch came out and I got my shipping notification, that guy (Jay Little) literally asked if the FedEx package was real.

I also made a forum post (on Purism, not Reddit) about asking how to charge the battery after a deep discharge (turns out I just needed to keep it plugged in to get it charged). That guy apparently goes through the Purism forum to find posts like mine because he THEN posted it to Reddit as proof that anyone investing in it is a moron and how I specifically am a moron.

He also said he personally despises the CEO of Purism.

That post was also before there was any hardware shipped. He was convinced hardware didn't exist and Purism was scamming everyone.

I say that to say I personally think that person is a troll or has some deep personal issues. I would not pay any attention to what he says.

</comment></comment></comment><comment><USER7> What is the current state of the software on the Librem 5? I would be happy to replace my main phone if it ticks the following boxes:

\- Can handle phone calls and texts

\- Cellular data works most of the time

\- Has the Signal app

\- Has a working web browser

<comment><USER2> Other than the signal app, it does all of what you ask. It does NOT do MMS (nor does the Pinephone, there is no software support on any of them).

I don't know if signal works in a web browser?

<comment><USER8> Signal does not work in a web browser. However, there is hope that either the Signal app for Android can be used on a Linux phone through a compatibility layer like Anbox, or at least the Signal desktop app can be made to work on a phone screen. This is still a long way off, though.

<comment><USER2> I know Anbox is sort of working in Mobian/pinephone. It isn't production quality, but it works!

</comment></comment></comment></comment><comment><USER9> It would be cool if someone ported Lineage to this board.

The hardware killswitches for the baseband, mic, and camera are amazing. But the linux desktop security model is super scary, especially on a phone.

<comment> yjftsjthsd-h > But the linux desktop security model is super scary, especially on a phone.

Depends on your threat model. If you want to run random untrusted apps, then yeah it's not great. If you run apps you trust out of curated repos, does it matter? If you want, stick stuff in firejail to close the gap.</comment></comment>


HTTP cookies, or how not to design protocols - <AUTHOR> http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html <comment><USER2> That's a nice summary!

I still think allowing cookies to span more than one distinct domain was a mistake. If we had avoided that in the beginning, cookie scope implementations would be dead simple and not much functionality would be lost on the server side. Also, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin. I postulate there are very few legitimate uses for document.cookie

<comment> mike-cardwell You can use the HttpOnly flag with a cookie to prevent JavaScript being able to access it. Here's a good summary:

<http://www.owasp.org/index.php/HttpOnly>

If you are serving a cookie, and JavaScript doesn't need to be able to access it, you _should_ set it to be HttpOnly to try and reduce the effects of an XSS.

<comment><AUTHOR> It doesn't seem like Michal is sold on HttpOnly and I definitely am not either; most everything you can do with a stolen cookie, you can also do quickly and silently using a captive browser during an XSS attack.

<comment><USER3> No cost, potential benefit. I've had to make harder decisions.

<comment><AUTHOR> The cost is "false sense of security", and believe me, from field work, that is a real cost. A majority of programmer applicants can't solve FizzBuzz, so you're deluded if you think that a good chunk of webdevs don't think "HttpOnly fixes XSS".

The potential benefit is... what, exactly?

<comment><USER2> It lessens your potential attack surface and comes at no cost. And as security-ignorant devs are concerned (which we all are from time to time) it doesn't magically fix vulnerabilities, but it can alleviate the magnitude of exploits. It's a good idea.

<comment><AUTHOR> Try to articulate how it lessens the attack surface. It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow. Remember in your explanation that session tokens already expire anyways.

<comment><USER2> By sending the HttpOnly flag as a server application, I indicate to the browser that it should prevent client-side scripts from obtaining the actual value of the cookie. Hence, it is more difficult for a malicious little piece of smuggled-in XSS code to steal my session id and ship it off to some Nigerian server. Is it circumventable? Yes. Are different browser implementations subverting this scheme? Yes. But is the intention behind it worthwhile? ...I think so.

Of course, that kind of protection is superficial, but please try to remember in your rebuttal there are actual attacks still happening that could have been prevented by setting this simple flag. An insistence on always making secure code that won't have this problem anyway is honorable but not realistic. By the way, it happens on high profile sites, too. It shouldn't, and it makes us web devs uncomfortable even observing it from a distance, but it still happens.

Even disregarding this argument, for me HttpOnly is the way cookies should have been conceived by default. I believe accessing cookie values by JavaScript is pathological. The behavior HttpOnly attempts to trigger on the client seems like good practice to me, and given (again) the point that it comes at no cost to the reasonable developer, turning it on is really a no- brainer. In fact, browsers should turn it on whether the flag is set or not.

 _It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow._

Oh, you can still use other exploits to bank up tokens, but yes this particular avenue is blocked. You're absolutely right, having the current session to work with is pretty destructive. But I think shipping off session IDs to a hostile server is worse than issuing false requests on behalf of the user in an already open browser window. That's because siphoning session IDs is silent and can lead to problems many days later when you're _not_ online.

 _Try to articulate [...] Remember in your explanation that session tokens already expire anyways._

Alright, I'll try not to drool and babble more than necessary: for the sake of convenience we are used to very long-lasting session tokens. So when you say they expire, yes, it limits the amount of damage somewhat, but not in any meaningful way considering the typical cookie-based account identifier lasts well beyond a week. Certainly for the purpose of completing my answer I can now say "I remembered" session expiration but it didn't really go anywhere.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> In my opinion, session cookies are primarily used as a work around since HTTP Authentication is incredibly ugly. Perhaps if that core problem was addressed, the need for cookies would be dramatically reduced.

<comment><USER5> I've never understood whats so "ugly" about http authentication. Digest auth can get a little verbose, to be sure, but Basic+SSL is simple, and both are far easier than roll-your-own Cookie auth. In fact, the way most people & frameworks implement cookie auth sessions are no less secure than Basic auth. Haven't the events of the past week demonstrated we should all be using SSL anyways, in which case Basic auth would be fine for everyone.

<comment><AUTHOR> Basic auth is only simpler than cookie auth if you (a) aren't using a modern web stack (ie, you aren't using ASP.NET, J2EE, Rails, Django, &c) _and_ (b) have only a few users.

If either (a) or (b) do not hold, Basic Auth is _at least_ as hard as cookie auth.

<comment> mike-cardwell I use HTTP authentication when I want to password protect a bunch of static files, or a third party web app. Using the PAM auth module with Apache is particularly nice. Just drop a few lines in a .htaccess file and it uses your users system credentials, eg /etc/passwd and /etc/shadow.

HTTP Authentication comes in several flavours. I've not done it myself, but I think you can do interesting things to with Kerberos. Good for Intranet systems.

HTTP Authentication does have its places.

<comment><AUTHOR> In other words, HTTP Authentication is useful in the same sense as FTP is useful: it's outmoded but sometimes convenient.

<comment> mike-cardwell HTTP Authentication is sessionless. In any scenario where you want to protect something without establishing and maintaining a session, it's useful.

The only large public website that I know of which still uses HTTP Authentication though is <http://www.123-reg.co.uk/>

<comment><AUTHOR> What's the browser app scenario in which having a session is a liability, but having a stored HTTP Auth credential isn't?

<comment><USER6> Actually the elimination of server side session reduces distributed application topology significantly. It is far easier to scale a stateless app than it is a statefull app.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> lcamtuf is amazing.

also: Lou Montulli did the blink tag. Hrmph!

<comment><AUTHOR> He really has gone from genuinely impressive to downright spooky in a pretty short period of time; he might be the smartest person doing browser security today.

That blog is just awesome, for what it's worth. He has yet to turn in a bad post.

<comment><USER7> I'm actually more enamored of the CAD and fabrication stuff: <http://lcamtuf.coredump.cx/guerrilla_cnc1.shtml>

</comment></comment></comment><comment><USER8> Would using javascript's same origin policy have solved 90% of the issues?

On the face of it that seems the case.</comment>


Draw in the air with a 3D printing pen - <AUTHOR> http://www.newstatesman.com/technology/2013/02/draw-air-3d-printing-pen <comment><USER2> This is already on the front page: <http://news.ycombinator.com/item?id=5243271></comment>


Ecuador says letter of safe conduct for Snowden is unauthorized and invalid - <AUTHOR> http://www.washingtonpost.com/world/the_americas/ecuador-says-letter-of-safe-conduct-for-snowden-is-real-but-unauthorized-and-invalid/2013/06/27/fe72008e-df2d-11e2-8cf3-35c1113cfcc5_story.html?tid=rssfeed

<comment><USER2> "She also threatened legal action against whoever had leaked the document." [http://i.imgur.com/tF3GHPY.jpg](http://i.imgur.com/tF3GHPY.jpg)

<comment><USER3> > _" She also threatened legal action against whoever had leaked the > document."_

I posted elsewhere, but is more appropriate here: The document itself struck me as checking for leaks. (Misspelled "hight"? No stamp?)

<comment><USER4> Please explain how typos help check for leaks

<comment><USER5> You give a different version of the document to each person, with unique typos in each one. If the document gets leaked, you know who did it - the typos form a "signature".

Sometimes a typo is just a typo though.

</comment></comment></comment></comment><comment><USER6> Hey, the content of this page changed! I found the original: [http://www.neurope.eu/news/wire/ecuador-says-letter-safe- con...](http://www.neurope.eu/news/wire/ecuador-says-letter-safe-conduct- snowden-real-unauthorized-and-invalid)</comment>


Design Trend: Long Shadows (Flat) - Examples - <AUTHOR> http://designmodo.com/long-shadows-design/ A new trend is making its way through cyberspace – long shadow design. The concept, which borrows themes from flat design, is popping up in a big way in recent weeks. <comment><USER2> While flat design done right is good design, especially on the web, I find clients immediately think the work looks "cheap," "unfinished," and "missing life." Seems like many clients still want wood grain and candy buttons. I like this shadow effect, it adds a little more to the design so, perhaps, clients may feel like they are getting more for their dollar if they get those drop shadows that "pop." Wow I sound jaded right now. But I'm not :)

I believe flat design is a solid trend (any design trend with roots in Swiss design are good, especially when organizing content), however these shadow effects are more of a fad that should be used sparingly.

<comment><AUTHOR> Completely agree with you there. I think in the right place it can give a different perspective. One of the above graphics looks like you're looking down onto a monument so to that degree it could be used but I know I wouldn't even get away with 'flat design' with most of my clients as they would say a 5-year-old had done it and it wasn't worth the price tag.

As with most things design it's about getting the appropriateness of technique to task.

</comment></comment><comment><USER3> This is not so much as a design trend as a designer's in-joke that is getting more attention than it deserves. While more dimensionality vs. texture and gradients for depth is definitely where things are going and this is part of it, it's like saying coughs are the new trend while there's a flu epidemic. If you're stuck emulating little techniques like this to stay current you're doing it wrong.</comment>