121–130 of 385 posts
JWZ identified the issue Miguel discusses in this post ten years ago, he even gave it a name: CADT http://www.jwz.org/doc/cadt.html Also, part of what killed the Linux desktop was Miguel and his total lack of understanding of the unix philosophy which drove him to create abominations like BONOBO. D-Bus is not much better either. That he fell in love with an iPhone goes to show he didn't fully appreciate the value of…
This whole thing about backward compatibility and the discussion that surrounds it is just vague. Here's a practical "true story" for you: I'm using GNU/Linux for more than 10 years now, and it is still alive.
Never had any vague binary compatibility problems either, because I'm not strangely expecting to use an ancient binary version of Gimp on my current system. That's because FOSS is source oriented, not binary. I'm not suddenly trying to use a 15 years old graphics card whose driver is longer in the kernel either, because I don't use a 15 years old graphics card.
What to do about it? Couple golang's preference for large statically-linked binaries with a one-folder, one-executable install convention and Linux may become more inviting for non-nix apps.
For example, imagine "/outside/myapp/myapp" is a large, unix-unfriendly, statically-compiled binary placed in it's folder by a OS-provided install utility. "Myapp" was probably developed for Mac or Windows and by design does not give a damn about /etc, /lib, /var, etc. These app should just be allowed to crap their configuration files into the home directory into which it has been placed ("/outside/myapp"). If one no longer needs the app, the folder is deleted along with everything else the app created while it was being used. Tidy. Behind the scenes such an app would be compiled to call the standard Linux APIs, yet it would probably avoid any dynamic dependencies. Disk space is cheap. Just bundle it all together and throw it somewhere where it can run in peace.
Amiga's icon files are another approach. Rather than a large, monolithic registry tracking everything in the system, executables exist in tandem with an "icon" (.info) file. This file is generated by the OS and tracks the executable's location and other settings in the workbench (desktop). A modern reincarnation could potentially track anything. Instead of accumulating registry filth with every uninstall one can simply remove an executable and its associated .info file. Instead of adhering to the heir convention, the app plays nicely in its own folder with it's own registry. By using an ".info" file, portable non-nix installs could reside anywhere, and not in a prefabbed "/outside" folder.
The smartphone penchant for portable installation should come to nix, particularly with non-unix software. It should be encouraged, and that's coming from an OpenBSD user. Unix needs a playground for non-unix apps.
I have a Mac, and use it for some things, at times. It's nice, for sure, but I love the openness of Linux, even though, of course, there can be many very painful hardware issues (video, sound, etc), all of which I have experienced at one time or another.
I am wondering - I hear Google is working on a "Android desktop". Would that perhaps maybe change things regarding the "Linux desktop" a bit?
Earlier quoted context omitted.
> Sure, they weren't, but it's not like Linux in general has given us much innovative things in the desktop space. O.o Two off the top of my head: workspaces, app stores.
Workspaces? You mean virtual desktops? Those date back 1986, implemented at Xerox PARC (and patented!). As for appstores, I assume you're talking about the packaging systems, which are similar only if viewed from 50,000 feet. The packaging systems were not stores. You couldn't buy packages. They didn't serve as an agent to sell other people's personally submitted packages. They had "apps" but no "store". The applicat…
However, no way in hell anyone will get me to switch to Mac OS. I am simply too enamored with having an environment that I can hack on if it strikes my fancy, as well as an environment that I can customize how I want it. Despite all its flaws, it still does focus follows mouse pretty well, and not having that would drive me batty.
Also, Apple is an 800 pound gorilla that has always been about Being In Control. The Samsung lawsuit wasn't anything new:
http://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Microso...
I just don't want to be part of that kind of walled garden.
Earlier quoted context omitted.
> I have two monitors on my Linux desktop. A month ago full screen on video stopped working. [...] In this regard, both Windows and OSX just work. Just because it's never happened to you on OS X or Windows doesn't mean it doesn't happen. OS X 10.6.7 broke the output on my 13" Macbook for either of the two external displays I own. Both worked fine previously, when booted from the install CDs, or from Linux on the same…
To stress out again; OS/X has the poorest hardware support for 3rd parties; even compared to Linux. Just "think different" and buy some hardware and you ll see what I mean..
This is the money quote: > The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use. Linux on the desktop suffered from a lack of coherent, strategic vision, consistency and philosophy . Every engineer I know likes to do things a particular way. They also have a distorted view on the level of customization that people want and need. I like OSX. Out o…
> I have two monitors on my Linux desktop. A month ago full screen on video stopped working. [...] In this regard, both Windows and OSX just work. Just because it's never happened to you on OS X or Windows doesn't mean it doesn't happen. OS X 10.6.7 broke the output on my 13" Macbook for either of the two external displays I own. Both worked fine previously, when booted from the install CDs, or from Linux on the same…
Straw man. Nobody said OS X was perfect.
> In my experience it's only been marginally better than Linux, if at all.
I used Linux on my desktop for several years and have now used Macs as well for several years. I won't say this is bullshit because I don't think you are lying about your experience, but I think you are extrapolating way too far.
> And with Linux you have some hope of finding a solution, whereas for OS X you're pretty much hosed.
Forums and mailing lists are "hope for a solution" while the genius bar is "pretty much hosed"? How on earth did you arrive at this conclusion? That just doesn't seem reasonable.
Earlier quoted context omitted.
Even windows, crappy as it may be, has it. [...] Apple's work looks pretty-- because it is designed to function well. Actually, I'd say the same of Windows, if not more so. I far prefer the Windows 7 interface to OSX, it's just stuff like the terminal/command prompt that really lets Windows down.
> I far prefer the Windows 7 interface to OSX, it's just stuff like the terminal/command prompt that really lets Windows down. I'm not sure. Windows has some overall design, but also has tons of design neglect. One example: due to static compiling and linking, you often get programs (and lots of them) that still use Windows 98 like Open/Save File dialogs, instead of every program automatically getting the latest OS s…
Software compiled in 1998 has no problem using the newest common dialogs if they used the standard API without installing their own hooks and customisation.
Earlier quoted context omitted.
So in that light, I think the idea that the Linux desktop got "killed" is sort of missing the point. It's no more moribund now than it was before. I strongly disagree. It is losing exactly the sort of person that the author is: developers who, all else equal, would rather use Linux. But who eventually get tired of the BS and just want something that works and you can actually get software for. I have a lot of sympath…
What are you using for sound? I use Pulseaudio on my desktop (custom built with a M-Audio Delta 2496 Pro soundcard) and on my laptop (crappy Lenovo G575) and I don't have any problems at all. All I do is have this line in my .xinitrc: [[ -x /usr/bin/start-pulseaudio-x11 ]] && start-pulseaudio-x11 & And it works perfectly! If I want to change my volume or manage which device it outputs on, I just run pavucontrol