Unless you are a special purpose OS (Embedded, Real Time, designed for certain classes of server etc.) what you really need to gain any sort of user base is applications. Very few people are interested in running an OS that doesn't have applications to do most of the the things they would like to do - and that's harder than it sounds: Yes, most people mostly just use web and email and word processing, but most people also usually have some other small niche application that they want to use as well; To get the broad userbase you need to support all those different small niche applications.
Look at it another way: What OSs have actually managed to gain some level on general support? Windows, obviously, then OS X, Linux and *BSD, and maybe you could throw in Solaris. After that you are into rather more niche material (like AIX, HP-UX, UNICOS etc.) designed for servers and the like. What do those OSs have in common? The ability to provide a wealth of appliations - though they do it by different means:
Windows - through ubiquity and market share: everyone writes apps for Windows.
OS X - by being able to promise application developers a market: Apple has always had a fairly solid hold on the graphics and design market, and enough general use that they can convince developers to write stuff for the Mac.
Linux and BSD - By being open source, and winning the open source market share. That is Linux and BSD are ubiquitous amongst open source developers - it's the Windows of the open source world.
Solaris - Well, it's more filling the niche big server market and any ability to cling to the desktop/workstation is by co-opting open source applications, which Sun have done a decent job of.
If a new OS (or some of those radical "Let's make Linux ultra standardised and easy like OS X" ideas) comes along it has to be able to attract applications: that means support open source applications for Linux and BSD with only a recompile, or be able to promise a guaranteed decent sized market of users to any potential app developers. The latter is very hard, and the former has the diffiulty of competing with the established Linux and BSDs.
Unless someone manages something truly radical I really don't expect anything but evolutionary changes in the existing OSs from here...
For me, it's Longhorn's vector-based approach to the UI. While everybody's busy giggling and snorting at the 'eye-candy' at Longhorn, the reality is you'll be able to use it on monitors with > 3,000 pixels in width without having to use a microscope to read the text. You'll be able to resize windows etc to suit your needs. I also really enjoy the idea of using the system's GPU to offload the graphical stuff.......Certainly Linux is going to have its own implementation of this feature set.
Vector based graphics, offloading work to the GPU? Linux has its own implementation of this featureset now. It is called Cairo, and it works right now. GTK+ is going to be using it very soon, and SWT already makes use of it for their "advanced graphics" system. If you want Cairo rendering of GTK+ right now, use the cairo-gtk theme engine and associated themes.
Is Cairo fully integrated in yet? No, development is still in the works to port things over to Cairo (but work on both Mozilla and OpenOffice is already underway as well). In a sense then while the backend has been hammered out (Cairo) the full end to end functionality is till in the works. Then again Longhorn is still a ways from release as well.
This does mark an interesting point though: Linux is not playing catchup with Windows on this one, they are running pretty much in parallel. Similarly Beagle is in parallel or ahead of WinFS. I know all the Mac people will complain that their both playing catchup with OS X, but let's take this one hurdle at a time. In terms of new features Linux is playing head to head with Windows these days, and considering how far behind they were when they started (or how far behind they were even a year or two ago) I would take that to mean that Linux will be running ahead of Windows and only a little behind OS X in another few years.
For extra fun: Open up Celestia (come on, you all should have a copy), and turn on consteallation drawing and labels. Admire all the signs of the Zodiac. Pick a star at random, select it, and hit "g" for "Go to". Now admire what all the signs of the Zodiac look like from a slightly different point in the Galaxy. For extra points, pick something nearby like Alpha Centauri to travel to.
Yes I'm sure those randomly scattered arbitrary selections of stars spread over vast galactic distances are meaningful. I'm sure that the fact that they all become skewed haphazard messes of huge long lines from any viewpoint other than the Earth is justone of those things.
OpenDX ( http://www.opendx.org/ ) is very powerful, and unlike VTK, it has free documentation.
VTK simply encourages you to buy their books - the books are in no way necessary to use VTK. They have quite comprehensive documentation which can be found online, downloaded as a tarball, or as compressed html, or if you like, generated from the source download via Doxygen.
If you want a less technical introduction, or a lon detailed explanation of how the 3D moelling technology works then the User's Guide or VTK Textbook may come in handy, but to claim they are charging to documentation is to say that Perl charges for documentation via the O'Reilly books. It is entirely optional, and a wealth of detailed tecnical documentation is already available for free.
I have used both OpenDX and VTK. It didn't take me long to see the clear benefits of VTK. Knowledge of any of C++, Java, Python, or Tcl will see you producing stuff in VTK very quickly and the variety and power of the libraries are far in advance of what OpenDX offers.
MPI is great. I used to work at a shop that had a lot of Sun workstations. After doing some reading I managed to recode some of our more processor intensive software to run distributed across the workstation pool (automatically reniced to lowest priority) using MPI. As long as you managed to get a large enough workstation pool (which wasn't that hard, given how many people had one sitting on their desk) the distributed version was every bit as fast as standard version running on high performance servers.
In effect, using MPI and a bit of recoding effort, I managed to double the number of available servers.
I have to add another vote for VTK. It's not ideal for 2D plots, but then there are so many packages that can do a good job of those. If you have to do any complex data representation in 3 or more dimensions however VTK is amazing, both in it's ability to produce great looking interactive plots, and in its incredible flexibility in how you trnasform and represent your data. Nothing else I'v used comes close.
It's a pretty standard deal for films, no matter how successful, to fail to make a "profit". There are a wide variety of ways that the studio manages to orchestrate this. There is a nice article here that outlines most of them.
Reading through all the little tricks and traps is a little frightening - things like the legacy "only 20% of actual home video receipts are booked, the remaining 80% goes to the studio as 'costs'", or the blanket exclusion of 50% of gross reciepts for merchandising and music are pretty blatant scamming. The rest is more subtle, but really just as bad. Read the whole thing, it's worth it.
The OO.o equation editor owes a lot to LaTeX - if you know LaTeX you can pretty much just use the OO.o equation editor by just typing the LaTeX with the backslashes left off.
Having said that, the output is quite simply not the least bit comparable. LaTeX equations are beautiful, and OO.o equations are just barely tolerable (at best).
If you must use OO.o for document preparation, but want pretty looking equations try this which allows you to insert proper LaTeX equation output into OO.o docs with ease (as well as making them conveniently easily editable).
Add in that they can stop at any point along the track completely safely if given enough warning and you have a much more convenient system of travel.
Safety is actually a big win. Yes flying is remarkably safe, but bullet trains have been operating exceedingly regularly along major routes in Japan since the early 60's. In all that time, with all those trains running, the total number of passenger deaths through accidents: 0. Not a single fatal incident for passengers. There has been the odd suicide (jumping on the tracks) and the odd inattentive railway worker... but basically as a passenger service the shinkansen have an exceptional safety record.
Without apps, an OS is nothing. Continuing to shrug off pursuit of some sort of standardized library base and directory layout is a sure way to guarantee that Linux-based distributions will never be a popular on the desktop.
Applications are indeed the key, and that is, in some ways, exactly why rigourous standardisation won't occur in Linux.
Let's be honest, the reason Linux is as popular as it is is because of the huge number of applications available for it - FOSS doesn't seem to be struggling to find developers willing to write new applications for FOSS OSs. The reality is that Linux is not going to be short of applications anytime in the near future.
Will Linux standardise? To some extent. There are some fairly loose standards like LSB, which give some rough guidelines for directory structures and libraries (and there are also distributions that don't follow LSB at all). Loose standards like that are not what you want. What you want is a firm mandated set of libraries that all distributions must install and synchronise versions of. That simply isn't going to happen - the distributions just won't do it: they compete to have the most stable (Debian) or the most bleeding edge (Gentoo) or the best mix (Mandrake, Ubuntu) or the most coporate oriented (SuSE, Redhat) versions of libraries; they compete as to which libraries are available, and which are default. Get Microsoft and Apple to agree on a common set of libraries that they will both always install, and will keep synchronised versions of, and I'll consider the possibility that you'll get some agreement from distributions... let's be honest though - it just won't happen.
So the other option is to start your own distribution and have mandated libraries that stay at fixed version numbers for healthy periods of time. You know what you'll get? A lack of applications. FOSS developers tend to code against the cutting edge. There are some great new applications that require recent versions of Mono (like Beagle and F-Spot) - you'll be out of date and unable to get them. Look at how much trouble Debian is in due to their slow release cycle - you're talking about basing a distribution on the concept of forcing such a slow release cycle. You'll get no developer support, and no applications, and the distribution will sink into utter obscurity.
I'm not foolish enough to pretend that Linux is and open source is the best for everything, there are some things that other models are better suited to - and OS X is, whith it's rigid enforced cathedral style model, much better suited to the desktop of someone who isn't prepared to trade off a little ease of use for some of the benefits of existing in the purely FOSS space. There's room for everyone.
To the average joe, there is Windows and Mac, period. A more education person will know about Windows, Mac, and Linux, but "Linux" doesn't really mean anything.
It is a very small percentage of computer users that know that Red Hat and Slackware are two different collections of libraries that happen to use the linux kernel.
I don't think this is quite the problem you seem to think. What we have to get past is the belief that there is a single system that is best for everyone. Once you are open to the existence of a plurality of systems then the different distributions seem far less frightening: hopping bewteen Fedora and SuSE and Ubuntu is far less daunting that moving from Mac to Windows or vice versa.
Is the diversity of Linux distributions holding Linux adoption back? Yes, probably a little. I think lack of critical mass in mind share is a far bigger issue however. And in many ways diversity of distributions helps Linux too, by providing vitality and competition: Look at what the arrival of Ubuntu has done for desktop linux.
Linux is making slow and steady inroads on the desktop, and that's fine. It will never be the dominant desktop OS because it's FOSS nature precludes the sort of mandated controlled consistency that a truly "Joe User desktop" really requires. It could easily garner a large share of the desktop market though, providing a good desktop for technical people, and other niche markets.
Let's be honest, no OS can be everything to everyone. If you want a consolidated, controlled, consistent OS where everything is simple because standards are locked down then I think OS X is great. If you want a little more flexibility and ready access to a fast evolving system then I think Linux is making good strides toward being an excellent desktop OS for your needs. If you want to something that has the majority of developers and commercial applications right now then Windows is probably a good option. I think there's plenty of room for in the market for a variety of different desktop OSs to suit the needs of different desktop users. All that really matters is that they play together and interact easily and well (it's on this last point that Windows falls down for me).
It's actually pretty good at what it is - a means to package a diverse system that can be tailored to the user. Things like Smart (a Conectiva/Mandriva project even) and Autopackage help a lot. To get the packaging systems you want you need to fix #4, and I don't think that's likely to happen (at least not successfully).
2. The locations of programs are user-unfriendly.
Really? Any program that actually supports the freedesktop.org desktop entry file is readily accessible to the user unless they use some WM or DE that doesn't bother to use them - which means they've gone out of their way to complicate their lives. As for where the programs are stored on disk... well, that doesn't really matter does it? You want a searchable tag/label based system, so why not consider the package database as such a label view - you can see all the programs on your system with ease through the "package label" view of your filesystem, does the physical location really matter that much to you?
3. The folder layout of Linux systems is user-unfriendly.
To some extent I agree, but we're dealing with legacy here... even OS X and windows have some odd folder locations and names carried over. Besides, there's always GoboLinux, which I presume you already know about.
4. The lack of a standard base of installed libraries is application (and thus user) unfriendly.
This is the big one really. If you want a fixed mandated core set of libraries that the user is forced to install... well, grab yourself a nice mandated controlled system like OS X, because Linux probably isn't what you're looking for. In theory you could just set up a distribution that has such a guaranteed base set of libraries, and in a sense some already exist - try Linspire, or Xandros. The catch is that people write applications for "Linux" not "Debian, stable" or "Linspire 3.1" or whatever. Given a random open source application it will make whatever assumptions about libraries it cares to - it's up to the packages to make sure those dependencies are met. FOSS applications tend to be coded against "whatever system the developer cared to use" rather than specific distributions and versions. Commercial developers maybe? Well they do have requirements - Oracle requires particular versions of Redhat in standard installs. Other commercial developers can do that if they like. Alternatively they could accept that the Linux world is a diverse world and restricting yourself to the one distribution that is guaranteed to have everything you want where you want it is a little limiting. You can always use Autopackage and handle the dependency issue elegantly in a way that's effectively invisible to the user.
The fact is that different distributions are different. You seem to be asking for all (or most) of the distributions to agree on a firm fixed set of base libraries. Distributions are different competing companies often however - you may as well ask Apple and Microsoft to hammer out a combined base set of libraries that you can be guaranteed to get in both OS X and Windows. Maybe that's a good idea. Maybe CoreImage on Windows and DirectX on OS X is what you'd like to see. I'm not so sure it will happen though.
Jedidiah.
Re:Only going to work if it became standard
on
Advocating Dvorak
·
· Score: 4, Insightful
One of the best programmers I've met, who could turn out good code at least as fast as anyone else I've ever met, typed with his feet (he had cerebral palsy). Sure, his WPM rate wasn't as high as most, but give him a decent editor and he'd fly along - mostly because he could think through his code very efficiently.
Of course Nokia has apparently taken webkit and built the GUI for it using GTK+. The result is GTK-WebKit, which has indeed been open sourced - you can find it here. I have no idea how much of their browser that contains, but at the least it is an HTML renderer and basic GUI, which should get you the better part of the browser whole.
Does a GTK+/KHTML browser count as cross desktop cooperation, or a mutant bastard offspring created by third party mad scientists?
Gosh, so it's sort of the bastard offspring of KDE, GNOME, and Apple. How very odd. I wonder if this will mean GNOME will get a webkit based browser in the near future.
I wonder how many people would have predicted that GNOME would gain the most from Apple taking up KHTML? Sure, we aren't there yet, but it begins to look possible. How very very odd.
I can think of one - and that's that if you e-book versions of all your textbooks you can have all your books for all your subjects in on single simple easily accessible device that even allows for rich content (animated and or 3D diagrams for biology and chemistry, sound files for music and poetry etc.)
Does that need to be a laptop computer? No, a halfway decently powered e-book reader/tablet (for maginal notes) would be entirely sufficient. Teaching using fancy software is highly overrated IMHO, and is mostly just an excuse to use the computer rather than a real attempt to teach the material.
The other issue is that screen reading just isn't the same as reading pages. Roll on decent e-paper or e-ink or whatever "e" name their calling it these days to replace backlit screens - we need display devices that use reflected light.
So yes, I think there's some value and good ideas in there, but I don't think we're quite at the point to do it as well as it really should be, and it still doesn't require full powered laptop computers.
First to answer the question. I doubt its their strategy. First because it's almost certainly filled with debugging code, is not optimized and is thus not going to benchmark att that hot. Second even if they wanted to it's probably loaded with other people's IP, like rosetta, that they cant just give out.
First, this is only going to end up the hands of serious geeks, no one is going to be able to find, download and get running this copy without some serius nouse and intent. Such people will, I suspect, view it as still containing debugging code and being forgiving.
Second, the implication is not that this was "deliberately released" by Apple, but rather that Apple was (should have been) aware (especially after the Tiger beta leaks) that if it could run on standard hardware with little change (and apparently it can) it will get leaked and pirated quite heavily. That is to say, they are claiming Apple simply provided developer editions that weren't excessively hard to pirate in the knowledge that they would get pirated. This gives them full legal deniability - Apple has not leaked this, and can claim they took all appropriate safeguards (NDAs, some basic anti pirating stuff etc.) Apple can just say "Oops, sorry!" as they technically didn't leak the software - they just put it out there with the full expectation that this would happen.
Whether you agree with that thesis or not is an interesting question, so please actually try arguing against what their claiming.
I don't care about success or quality, I'm asking what numbers they plugged into their formulas to get the very different results - I see no significant differences in the scores for the variables they used - but perhaps you can tell me which of R, D, V, S, F, and A where so startlingly different for Blackadder and The Office or Fawlty Towers and Only Fools and Horses.
For the record I am just as much a fan of The Office and Only Fools and Horses as Blackadder and Fawlty Towers - I just can't see why the scored so differently (beyond random "pull numbers out of your ass" subjectivity which, let's face it, is no diffferent than pulling a single "S = successfulness of sitcom" score out of your ass).
Seems like an interesting pile of horseshit, as it usual for these "mathematical formula for..." stories.
Can someone explain to me how exactly Blackadder and Fawlty Towers scored so relatively low compared to The Office and Only Fools and Horses? Are Edmund or Basil notably less "Recognisable" or "Deluded" about their grandeur than Del or David? Certainly there are about the same number of successful plans, and at least the same level of difference in social status (Edmund is to Baldrick as Del is to... nope, I'm drawing a blank). The only things left are "Verbal wit in the script" and "Number of times someone falls over or is injured"... is Only Fools and Horses really that much wittier than Blackadder? Does The Office really have that many more pratfalls and injuries than Fawlty Towers?
I think it's nice that they've come up with a half assed justification to prefer their favourite comedies, but it really isn't significantly less subjective than asking a random person whether they like the show or not.
From what I gather (I'm not a KDE expert either) DCOP does expose roughly such an interface - but not at the shell level (which is what the virtual FS part achieves so nicely). Anything that uses libglade under GNOME (from what I gather) ought to be able to trivially expose such a window and widget tree as well. What I'm asking for is a standardised procfs filesystem that can unite X, DCOP, Glade etc. into a single consistently addressable system. The fact that there are things like DCOP out there means that this shouldn't be that hard to do, not that it has already been done.
The keywords here are: standardised, consistent, and addressable via normal shell operations.
And Plan 9 had actual network access via devices you can access from the command line; I saw a simple script that actually implemented a subset of FTP.
I don't think there's much else you can do from the command line, and I don't expect that we're going to be really impressed with this new Microsoft Shell.
The "sometime smentioned" feature that I would liketo see come to shells isn't a shell issue so much as a windowing and FS issue - in a similar way to procfs and Plan9's network device access, it would be nice to have access to the graphical environment via some sort of virtual file system:
grep -ri llamma/proc/win//frame1/text_entry
sort of thing. Presuming the widget tree could be well organised this would be great. Grab the contents of any window from the shell. Have shell access to the GUIs of any running program (up to file permissions of course). It gives you good access, and you can just use the existing file based security controls to make sure things don't get out of hand.
The security model of (most) Linux systems still assumes the fact that a binary being on the hard disk means that it should be entitled to every single permission associated with the user when run.
I think it is important to note that this is the security model that is on the way out. LSM and whatever hooks to it (be it SELinux or something else) veers notably away from this model. We shouldn't be making any assumptions or else we'll end up in a morass similar to that Windows is in where every application assumes that it is perfectly reasonable to ask for full Administrator priviliges all the time.
Perhaps it is time Linux installs started looking into SELinux and seeing how they can take advantage of that to make user installs easier, yet still able to be suitably and elegantly locked down.
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.
I'm really not so sure that would work as well as you suggest. Many of the distros survive by letting you install as much or as little as you want, by letting use GNOME or KDE or XFCE or *box or play with dev versions of E17. The distros themselves work hard to remain flexible in what software they suck up and include in the distribution.
I'm sure, if you wanted to you could mandate a firm API - just don't expect FOSS developers to necessarily agree and develop against the paritcular APIs you chose. Try telling the Firefox crew to abandon XUL and use pure GTK+ or QT. Who knows where the next must have app will come from - maybe someone will develop a truly revolutionary new "must have" application using Mono - are you using Mono for your mandated API?
There is as much life and vitality in FOSS as there is because the developer can use whatever library, whatever API suits his or her needs. The distributions, in turn, keep an open and flexible system to make it easy to add new libraries or applications using new or different or otherwise obscure APIs.
Linux, I think, does as well as it does because it can rally such a vast array of applications, and it does that by supporting applications using the console, pure GTK+, QT, GNOME, KDElibs, FLTK, Edje, XUL, Mono, or whatever takes your fancy. Apple does well because it has cornered a niche and has a pretty guaranteed market, so plenty of people are willing to develop for it - particularly in the commercial software for designers realm. Apple also gets support via Fink, but from what I gather that's back to the dependency management and lack of rigid APIs thatb you're complaining about. A new OS, or distro is not going to get much use if it can't get enough applications - if you can't promise a market like Apple can, and you can't promise freedom to develop however you like as Linux can, well... I suspect you end up like BeOS and NeXT, just hoping you can get bought out by someone bigger.
Most of the basic tools are already in place, except for this "meta-debs", but these would be easy to implement
It has effectively been done: Autopackage. There are some quirks because it tires to be distro agnostic, and hence can't assume too much in the way of default installed libraries, but the end results are excellent: it does exactly as you suggest - checks the file system for the libraries (and versions) it needs and if it can't find it downloads and installs those (as autopackages) too. It even allows for nice things like fallback functionality (use the new GTK file dialogs if GTK+2.4 is present, use the older file dialog otherwise). The only catch is that the app developers actually have to do a little bit (surprisingly little really) to make all this happen and create autopackages.
True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.
And that's a very lovely idea and will make for very easy packag installation. It is not something you'll ever get on FOSS Linux however. The FOSS software community improves it software in an evolutionary sort of way - you get a whole lot of different versions of basic libraries and tools, and eventually you get some consensus on them. The key is that the whole system can be overturned - perhaps E17 will turn out to be truly amazing and a shift will occur, perhaps Y-Windows will get completed and turn out to be well worth pursuing... the point is that these decisions are made not by corporate management, but simply by what manages to get the most hackers interested in and coding for/with it.
What I'm really trying to say is that FOSS is utterly chaotic, but draws strength from those chaotic qualities. What you're talking about is eliminating some of that chaos - and I think there's certainly merit in that idea, I just don't think it will mix well with FOSS. If you want a organised mandated structured set of required libraries and APIs use Apple (or start your own OS). If you want the masses of software and vitality of the FOSS world, you have to accept a certain amount of chaos in return. What we need is better mays of managing that chaos: I don't think we can eliminate it.
Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.
But things are getting better. Check out Smart a new dependency resolver with far better algorithms than apt (along with more flexibility at the backend package level). As I said, I don't think you can eliminate the chaos, but you can do a lot better job of dealing with it.
Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.
And that's where things like Autopackage come in. As long as your base libraries are managed by something like Smart, then Autopackage is fine for those 3rd party extras - it will use the libraries if you have them, but it can grab whatever else it needs if you don't.
Don't fight FOSS's strengths, instead figure out how best to cope with the weaknesses that are the flipside of the strengths.
Slashdot Mirror
Unless you are a special purpose OS (Embedded, Real Time, designed for certain classes of server etc.) what you really need to gain any sort of user base is applications. Very few people are interested in running an OS that doesn't have applications to do most of the the things they would like to do - and that's harder than it sounds: Yes, most people mostly just use web and email and word processing, but most people also usually have some other small niche application that they want to use as well; To get the broad userbase you need to support all those different small niche applications.
Look at it another way: What OSs have actually managed to gain some level on general support? Windows, obviously, then OS X, Linux and *BSD, and maybe you could throw in Solaris. After that you are into rather more niche material (like AIX, HP-UX, UNICOS etc.) designed for servers and the like. What do those OSs have in common? The ability to provide a wealth of appliations - though they do it by different means:
Windows - through ubiquity and market share: everyone writes apps for Windows.
OS X - by being able to promise application developers a market: Apple has always had a fairly solid hold on the graphics and design market, and enough general use that they can convince developers to write stuff for the Mac.
Linux and BSD - By being open source, and winning the open source market share. That is Linux and BSD are ubiquitous amongst open source developers - it's the Windows of the open source world.
Solaris - Well, it's more filling the niche big server market and any ability to cling to the desktop/workstation is by co-opting open source applications, which Sun have done a decent job of.
If a new OS (or some of those radical "Let's make Linux ultra standardised and easy like OS X" ideas) comes along it has to be able to attract applications: that means support open source applications for Linux and BSD with only a recompile, or be able to promise a guaranteed decent sized market of users to any potential app developers. The latter is very hard, and the former has the diffiulty of competing with the established Linux and BSDs.
Unless someone manages something truly radical I really don't expect anything but evolutionary changes in the existing OSs from here...
Jedidiah.
For me, it's Longhorn's vector-based approach to the UI. While everybody's busy giggling and snorting at the 'eye-candy' at Longhorn, the reality is you'll be able to use it on monitors with > 3,000 pixels in width without having to use a microscope to read the text. You'll be able to resize windows etc to suit your needs. I also really enjoy the idea of using the system's GPU to offload the graphical stuff.... ...Certainly Linux is going to have its own implementation of this feature set.
Vector based graphics, offloading work to the GPU? Linux has its own implementation of this featureset now. It is called Cairo, and it works right now. GTK+ is going to be using it very soon, and SWT already makes use of it for their "advanced graphics" system. If you want Cairo rendering of GTK+ right now, use the cairo-gtk theme engine and associated themes.
Is Cairo fully integrated in yet? No, development is still in the works to port things over to Cairo (but work on both Mozilla and OpenOffice is already underway as well). In a sense then while the backend has been hammered out (Cairo) the full end to end functionality is till in the works. Then again Longhorn is still a ways from release as well.
This does mark an interesting point though: Linux is not playing catchup with Windows on this one, they are running pretty much in parallel. Similarly Beagle is in parallel or ahead of WinFS. I know all the Mac people will complain that their both playing catchup with OS X, but let's take this one hurdle at a time. In terms of new features Linux is playing head to head with Windows these days, and considering how far behind they were when they started (or how far behind they were even a year or two ago) I would take that to mean that Linux will be running ahead of Windows and only a little behind OS X in another few years.
Jedidiah.
For extra fun: Open up Celestia (come on, you all should have a copy), and turn on consteallation drawing and labels. Admire all the signs of the Zodiac. Pick a star at random, select it, and hit "g" for "Go to". Now admire what all the signs of the Zodiac look like from a slightly different point in the Galaxy. For extra points, pick something nearby like Alpha Centauri to travel to.
Yes I'm sure those randomly scattered arbitrary selections of stars spread over vast galactic distances are meaningful. I'm sure that the fact that they all become skewed haphazard messes of huge long lines from any viewpoint other than the Earth is justone of those things.
Jedidiah.
OpenDX ( http://www.opendx.org/ ) is very powerful, and unlike VTK, it has free documentation.
VTK simply encourages you to buy their books - the books are in no way necessary to use VTK. They have quite comprehensive documentation which can be found online, downloaded as a tarball, or as compressed html, or if you like, generated from the source download via Doxygen.
If you want a less technical introduction, or a lon detailed explanation of how the 3D moelling technology works then the User's Guide or VTK Textbook may come in handy, but to claim they are charging to documentation is to say that Perl charges for documentation via the O'Reilly books. It is entirely optional, and a wealth of detailed tecnical documentation is already available for free.
I have used both OpenDX and VTK. It didn't take me long to see the clear benefits of VTK. Knowledge of any of C++, Java, Python, or Tcl will see you producing stuff in VTK very quickly and the variety and power of the libraries are far in advance of what OpenDX offers.
Jedidiah.
MPI is great. I used to work at a shop that had a lot of Sun workstations. After doing some reading I managed to recode some of our more processor intensive software to run distributed across the workstation pool (automatically reniced to lowest priority) using MPI. As long as you managed to get a large enough workstation pool (which wasn't that hard, given how many people had one sitting on their desk) the distributed version was every bit as fast as standard version running on high performance servers.
In effect, using MPI and a bit of recoding effort, I managed to double the number of available servers.
Jedidiah.
I have to add another vote for VTK. It's not ideal for 2D plots, but then there are so many packages that can do a good job of those. If you have to do any complex data representation in 3 or more dimensions however VTK is amazing, both in it's ability to produce great looking interactive plots, and in its incredible flexibility in how you trnasform and represent your data. Nothing else I'v used comes close.
Jedidiah.
It's a pretty standard deal for films, no matter how successful, to fail to make a "profit". There are a wide variety of ways that the studio manages to orchestrate this. There is a nice article here that outlines most of them.
Reading through all the little tricks and traps is a little frightening - things like the legacy "only 20% of actual home video receipts are booked, the remaining 80% goes to the studio as 'costs'", or the blanket exclusion of 50% of gross reciepts for merchandising and music are pretty blatant scamming. The rest is more subtle, but really just as bad. Read the whole thing, it's worth it.
Jedidiah
The OO.o equation editor owes a lot to LaTeX - if you know LaTeX you can pretty much just use the OO.o equation editor by just typing the LaTeX with the backslashes left off.
Having said that, the output is quite simply not the least bit comparable. LaTeX equations are beautiful, and OO.o equations are just barely tolerable (at best).
If you must use OO.o for document preparation, but want pretty looking equations try this which allows you to insert proper LaTeX equation output into OO.o docs with ease (as well as making them conveniently easily editable).
Jedidiah.
Add in that they can stop at any point along the track completely safely if given enough warning and you have a much more convenient system of travel.
Safety is actually a big win. Yes flying is remarkably safe, but bullet trains have been operating exceedingly regularly along major routes in Japan since the early 60's. In all that time, with all those trains running, the total number of passenger deaths through accidents: 0. Not a single fatal incident for passengers. There has been the odd suicide (jumping on the tracks) and the odd inattentive railway worker... but basically as a passenger service the shinkansen have an exceptional safety record.
Jedidiah,
Without apps, an OS is nothing. Continuing to shrug off pursuit of some sort of standardized library base and directory layout is a sure way to guarantee that Linux-based distributions will never be a popular on the desktop.
Applications are indeed the key, and that is, in some ways, exactly why rigourous standardisation won't occur in Linux.
Let's be honest, the reason Linux is as popular as it is is because of the huge number of applications available for it - FOSS doesn't seem to be struggling to find developers willing to write new applications for FOSS OSs. The reality is that Linux is not going to be short of applications anytime in the near future.
Will Linux standardise? To some extent. There are some fairly loose standards like LSB, which give some rough guidelines for directory structures and libraries (and there are also distributions that don't follow LSB at all). Loose standards like that are not what you want. What you want is a firm mandated set of libraries that all distributions must install and synchronise versions of. That simply isn't going to happen - the distributions just won't do it: they compete to have the most stable (Debian) or the most bleeding edge (Gentoo) or the best mix (Mandrake, Ubuntu) or the most coporate oriented (SuSE, Redhat) versions of libraries; they compete as to which libraries are available, and which are default. Get Microsoft and Apple to agree on a common set of libraries that they will both always install, and will keep synchronised versions of, and I'll consider the possibility that you'll get some agreement from distributions... let's be honest though - it just won't happen.
So the other option is to start your own distribution and have mandated libraries that stay at fixed version numbers for healthy periods of time. You know what you'll get? A lack of applications. FOSS developers tend to code against the cutting edge. There are some great new applications that require recent versions of Mono (like Beagle and F-Spot) - you'll be out of date and unable to get them. Look at how much trouble Debian is in due to their slow release cycle - you're talking about basing a distribution on the concept of forcing such a slow release cycle. You'll get no developer support, and no applications, and the distribution will sink into utter obscurity.
I'm not foolish enough to pretend that Linux is and open source is the best for everything, there are some things that other models are better suited to - and OS X is, whith it's rigid enforced cathedral style model, much better suited to the desktop of someone who isn't prepared to trade off a little ease of use for some of the benefits of existing in the purely FOSS space. There's room for everyone.
Jedidiah.
To the average joe, there is Windows and Mac, period. A more education person will know about Windows, Mac, and Linux, but "Linux" doesn't really mean anything.
It is a very small percentage of computer users that know that Red Hat and Slackware are two different collections of libraries that happen to use the linux kernel.
I don't think this is quite the problem you seem to think. What we have to get past is the belief that there is a single system that is best for everyone. Once you are open to the existence of a plurality of systems then the different distributions seem far less frightening: hopping bewteen Fedora and SuSE and Ubuntu is far less daunting that moving from Mac to Windows or vice versa.
Is the diversity of Linux distributions holding Linux adoption back? Yes, probably a little. I think lack of critical mass in mind share is a far bigger issue however. And in many ways diversity of distributions helps Linux too, by providing vitality and competition: Look at what the arrival of Ubuntu has done for desktop linux.
Linux is making slow and steady inroads on the desktop, and that's fine. It will never be the dominant desktop OS because it's FOSS nature precludes the sort of mandated controlled consistency that a truly "Joe User desktop" really requires. It could easily garner a large share of the desktop market though, providing a good desktop for technical people, and other niche markets.
Let's be honest, no OS can be everything to everyone. If you want a consolidated, controlled, consistent OS where everything is simple because standards are locked down then I think OS X is great. If you want a little more flexibility and ready access to a fast evolving system then I think Linux is making good strides toward being an excellent desktop OS for your needs. If you want to something that has the majority of developers and commercial applications right now then Windows is probably a good option. I think there's plenty of room for in the market for a variety of different desktop OSs to suit the needs of different desktop users. All that really matters is that they play together and interact easily and well (it's on this last point that Windows falls down for me).
Jedidiah.
1. The packaging system is user-unfriendly.
... well, that doesn't really matter does it? You want a searchable tag/label based system, so why not consider the package database as such a label view - you can see all the programs on your system with ease through the "package label" view of your filesystem, does the physical location really matter that much to you?
It's actually pretty good at what it is - a means to package a diverse system that can be tailored to the user. Things like Smart (a Conectiva/Mandriva project even) and Autopackage help a lot. To get the packaging systems you want you need to fix #4, and I don't think that's likely to happen (at least not successfully).
2. The locations of programs are user-unfriendly.
Really? Any program that actually supports the freedesktop.org desktop entry file is readily accessible to the user unless they use some WM or DE that doesn't bother to use them - which means they've gone out of their way to complicate their lives. As for where the programs are stored on disk
3. The folder layout of Linux systems is user-unfriendly.
To some extent I agree, but we're dealing with legacy here... even OS X and windows have some odd folder locations and names carried over. Besides, there's always GoboLinux, which I presume you already know about.
4. The lack of a standard base of installed libraries is application (and thus user) unfriendly.
This is the big one really. If you want a fixed mandated core set of libraries that the user is forced to install... well, grab yourself a nice mandated controlled system like OS X, because Linux probably isn't what you're looking for. In theory you could just set up a distribution that has such a guaranteed base set of libraries, and in a sense some already exist - try Linspire, or Xandros. The catch is that people write applications for "Linux" not "Debian, stable" or "Linspire 3.1" or whatever. Given a random open source application it will make whatever assumptions about libraries it cares to - it's up to the packages to make sure those dependencies are met. FOSS applications tend to be coded against "whatever system the developer cared to use" rather than specific distributions and versions. Commercial developers maybe? Well they do have requirements - Oracle requires particular versions of Redhat in standard installs. Other commercial developers can do that if they like. Alternatively they could accept that the Linux world is a diverse world and restricting yourself to the one distribution that is guaranteed to have everything you want where you want it is a little limiting. You can always use Autopackage and handle the dependency issue elegantly in a way that's effectively invisible to the user.
The fact is that different distributions are different. You seem to be asking for all (or most) of the distributions to agree on a firm fixed set of base libraries. Distributions are different competing companies often however - you may as well ask Apple and Microsoft to hammer out a combined base set of libraries that you can be guaranteed to get in both OS X and Windows. Maybe that's a good idea. Maybe CoreImage on Windows and DirectX on OS X is what you'd like to see. I'm not so sure it will happen though.
Jedidiah.
One of the best programmers I've met, who could turn out good code at least as fast as anyone else I've ever met, typed with his feet (he had cerebral palsy). Sure, his WPM rate wasn't as high as most, but give him a decent editor and he'd fly along - mostly because he could think through his code very efficiently.
Typing speed for coding is vastly overrated.
Jedidiah.
Of course Nokia has apparently taken webkit and built the GUI for it using GTK+. The result is GTK-WebKit, which has indeed been open sourced - you can find it here. I have no idea how much of their browser that contains, but at the least it is an HTML renderer and basic GUI, which should get you the better part of the browser whole.
Does a GTK+/KHTML browser count as cross desktop cooperation, or a mutant bastard offspring created by third party mad scientists?
Jedidiah.
Gosh, so it's sort of the bastard offspring of KDE, GNOME, and Apple. How very odd. I wonder if this will mean GNOME will get a webkit based browser in the near future.
I wonder how many people would have predicted that GNOME would gain the most from Apple taking up KHTML? Sure, we aren't there yet, but it begins to look possible. How very very odd.
Jedidiah.
Whats the advantage to a laptop for study?
I can think of one - and that's that if you e-book versions of all your textbooks you can have all your books for all your subjects in on single simple easily accessible device that even allows for rich content (animated and or 3D diagrams for biology and chemistry, sound files for music and poetry etc.)
Does that need to be a laptop computer? No, a halfway decently powered e-book reader/tablet (for maginal notes) would be entirely sufficient. Teaching using fancy software is highly overrated IMHO, and is mostly just an excuse to use the computer rather than a real attempt to teach the material.
The other issue is that screen reading just isn't the same as reading pages. Roll on decent e-paper or e-ink or whatever "e" name their calling it these days to replace backlit screens - we need display devices that use reflected light.
So yes, I think there's some value and good ideas in there, but I don't think we're quite at the point to do it as well as it really should be, and it still doesn't require full powered laptop computers.
Jedidiah.
First to answer the question. I doubt its their strategy. First because it's almost certainly filled with debugging code, is not optimized and is thus not going to benchmark att that hot. Second even if they wanted to it's probably loaded with other people's IP, like rosetta, that they cant just give out.
First, this is only going to end up the hands of serious geeks, no one is going to be able to find, download and get running this copy without some serius nouse and intent. Such people will, I suspect, view it as still containing debugging code and being forgiving.
Second, the implication is not that this was "deliberately released" by Apple, but rather that Apple was (should have been) aware (especially after the Tiger beta leaks) that if it could run on standard hardware with little change (and apparently it can) it will get leaked and pirated quite heavily. That is to say, they are claiming Apple simply provided developer editions that weren't excessively hard to pirate in the knowledge that they would get pirated. This gives them full legal deniability - Apple has not leaked this, and can claim they took all appropriate safeguards (NDAs, some basic anti pirating stuff etc.) Apple can just say "Oops, sorry!" as they technically didn't leak the software - they just put it out there with the full expectation that this would happen.
Whether you agree with that thesis or not is an interesting question, so please actually try arguing against what their claiming.
Jedidiah.
I don't care about success or quality, I'm asking what numbers they plugged into their formulas to get the very different results - I see no significant differences in the scores for the variables they used - but perhaps you can tell me which of R, D, V, S, F, and A where so startlingly different for Blackadder and The Office or Fawlty Towers and Only Fools and Horses.
For the record I am just as much a fan of The Office and Only Fools and Horses as Blackadder and Fawlty Towers - I just can't see why the scored so differently (beyond random "pull numbers out of your ass" subjectivity which, let's face it, is no diffferent than pulling a single "S = successfulness of sitcom" score out of your ass).
Jedidiah.
Seems like an interesting pile of horseshit, as it usual for these "mathematical formula for ..." stories.
... nope, I'm drawing a blank). The only things left are "Verbal wit in the script" and "Number of times someone falls over or is injured" ... is Only Fools and Horses really that much wittier than Blackadder? Does The Office really have that many more pratfalls and injuries than Fawlty Towers?
Can someone explain to me how exactly Blackadder and Fawlty Towers scored so relatively low compared to The Office and Only Fools and Horses? Are Edmund or Basil notably less "Recognisable" or "Deluded" about their grandeur than Del or David? Certainly there are about the same number of successful plans, and at least the same level of difference in social status (Edmund is to Baldrick as Del is to
I think it's nice that they've come up with a half assed justification to prefer their favourite comedies, but it really isn't significantly less subjective than asking a random person whether they like the show or not.
Jedidiah.
From what I gather (I'm not a KDE expert either) DCOP does expose roughly such an interface - but not at the shell level (which is what the virtual FS part achieves so nicely). Anything that uses libglade under GNOME (from what I gather) ought to be able to trivially expose such a window and widget tree as well. What I'm asking for is a standardised procfs filesystem that can unite X, DCOP, Glade etc. into a single consistently addressable system. The fact that there are things like DCOP out there means that this shouldn't be that hard to do, not that it has already been done.
The keywords here are: standardised, consistent, and addressable via normal shell operations.
Jedidiah.
And Plan 9 had actual network access via devices you can access from the command line; I saw a simple script that actually implemented a subset of FTP.
/proc/win//frame1/text_entry
I don't think there's much else you can do from the command line, and I don't expect that we're going to be really impressed with this new Microsoft Shell.
The "sometime smentioned" feature that I would liketo see come to shells isn't a shell issue so much as a windowing and FS issue - in a similar way to procfs and Plan9's network device access, it would be nice to have access to the graphical environment via some sort of virtual file system:
grep -ri llamma
sort of thing. Presuming the widget tree could be well organised this would be great. Grab the contents of any window from the shell. Have shell access to the GUIs of any running program (up to file permissions of course). It gives you good access, and you can just use the existing file based security controls to make sure things don't get out of hand.
Jedidiah.
The security model of (most) Linux systems still assumes the fact that a binary being on the hard disk means that it should be entitled to every single permission associated with the user when run.
I think it is important to note that this is the security model that is on the way out. LSM and whatever hooks to it (be it SELinux or something else) veers notably away from this model. We shouldn't be making any assumptions or else we'll end up in a morass similar to that Windows is in where every application assumes that it is perfectly reasonable to ask for full Administrator priviliges all the time.
Perhaps it is time Linux installs started looking into SELinux and seeing how they can take advantage of that to make user installs easier, yet still able to be suitably and elegantly locked down.
Jedidiah.
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.
I'm really not so sure that would work as well as you suggest. Many of the distros survive by letting you install as much or as little as you want, by letting use GNOME or KDE or XFCE or *box or play with dev versions of E17. The distros themselves work hard to remain flexible in what software they suck up and include in the distribution.
I'm sure, if you wanted to you could mandate a firm API - just don't expect FOSS developers to necessarily agree and develop against the paritcular APIs you chose. Try telling the Firefox crew to abandon XUL and use pure GTK+ or QT. Who knows where the next must have app will come from - maybe someone will develop a truly revolutionary new "must have" application using Mono - are you using Mono for your mandated API?
There is as much life and vitality in FOSS as there is because the developer can use whatever library, whatever API suits his or her needs. The distributions, in turn, keep an open and flexible system to make it easy to add new libraries or applications using new or different or otherwise obscure APIs.
Linux, I think, does as well as it does because it can rally such a vast array of applications, and it does that by supporting applications using the console, pure GTK+, QT, GNOME, KDElibs, FLTK, Edje, XUL, Mono, or whatever takes your fancy. Apple does well because it has cornered a niche and has a pretty guaranteed market, so plenty of people are willing to develop for it - particularly in the commercial software for designers realm. Apple also gets support via Fink, but from what I gather that's back to the dependency management and lack of rigid APIs thatb you're complaining about. A new OS, or distro is not going to get much use if it can't get enough applications - if you can't promise a market like Apple can, and you can't promise freedom to develop however you like as Linux can, well... I suspect you end up like BeOS and NeXT, just hoping you can get bought out by someone bigger.
Jedidiah.
Most of the basic tools are already in place, except for this "meta-debs", but these would be easy to implement
It has effectively been done: Autopackage. There are some quirks because it tires to be distro agnostic, and hence can't assume too much in the way of default installed libraries, but the end results are excellent: it does exactly as you suggest - checks the file system for the libraries (and versions) it needs and if it can't find it downloads and installs those (as autopackages) too. It even allows for nice things like fallback functionality (use the new GTK file dialogs if GTK+2.4 is present, use the older file dialog otherwise). The only catch is that the app developers actually have to do a little bit (surprisingly little really) to make all this happen and create autopackages.
Jedidiah.
True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.
And that's a very lovely idea and will make for very easy packag installation. It is not something you'll ever get on FOSS Linux however. The FOSS software community improves it software in an evolutionary sort of way - you get a whole lot of different versions of basic libraries and tools, and eventually you get some consensus on them. The key is that the whole system can be overturned - perhaps E17 will turn out to be truly amazing and a shift will occur, perhaps Y-Windows will get completed and turn out to be well worth pursuing... the point is that these decisions are made not by corporate management, but simply by what manages to get the most hackers interested in and coding for/with it.
What I'm really trying to say is that FOSS is utterly chaotic, but draws strength from those chaotic qualities. What you're talking about is eliminating some of that chaos - and I think there's certainly merit in that idea, I just don't think it will mix well with FOSS. If you want a organised mandated structured set of required libraries and APIs use Apple (or start your own OS). If you want the masses of software and vitality of the FOSS world, you have to accept a certain amount of chaos in return. What we need is better mays of managing that chaos: I don't think we can eliminate it.
Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.
But things are getting better. Check out Smart a new dependency resolver with far better algorithms than apt (along with more flexibility at the backend package level). As I said, I don't think you can eliminate the chaos, but you can do a lot better job of dealing with it.
Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.
And that's where things like Autopackage come in. As long as your base libraries are managed by something like Smart, then Autopackage is fine for those 3rd party extras - it will use the libraries if you have them, but it can grab whatever else it needs if you don't.
Don't fight FOSS's strengths, instead figure out how best to cope with the weaknesses that are the flipside of the strengths.
Jedidiah.