How is E17 progressing? I tried to keep up with the lists for a while, but it's too hard to understand where it's up to, and dependancy hell makes it too hard to build from source (and i'm too lazy). I did try it once, but that was some time ago.
Which is exactly what Apple recommends that developers do.
Yeah, most commercial operating systems don't deal with dependancies. I can understand why, it's bloody difficult. Bear in mind large amounts of code sharing which is the de facto standard on Linux simply does not exist on other operating systems, although Windows gets the closest with COM. There is practically no code sharing on OS X, OmniNetwork or whatever it's called is the only example I can think of. The type of dep management we need on Linux would be overkill for them, it's easiest to statically link, despite the well known problems with that approach.
Note that despite the whinging you'll find here on slashdot, Linux cannot, will never be like MacOS or Windows. Linux systems are best visualised as floating pools of components - the flexibility that comes with freedom and openness means you can't make many assumptions about the system. For instance, all installations of Windows and OS X have a graphics layer, a widget toolkit etc. They cannot be turned off. For servers, this is just bloat, which is why it's optional in Linux, but that also means you can't assume there is graphics support when you install an app. Equally, there is healthy competition between frameworks and APIs and due the way Linux is developed (more like grown), you can never assume the API/runtime you want to use is present.
Therefore dep management is essential, absolutely critical for maintaining the freedom and flexibility that Linux is famed for. Yes, it's hard, but hey, the end result will kick ass. Oh BTW the "large hard disk" excuse is getting old - that's the sort of thing poor engineers have said since the beginning of time to excuse inefficiency and it usually covers up deeper problems (static linking is also insecure and wastes memory, normally a far more pressing problem than disk space).
You're not going to get a good impression. The fact is that PowerPC is a minority platform in a minority platform, and PPC linux is generally inferior to the same distro even on x86 - the potential market is so much larger. If you try Yellow Dog or Mandrake PPC you will walk away disappointed, so if you want to try Linux do yourself a favour and use a PC.
I've seen this before, a Mac user friend wanted to look into Linux because OS X was so slow on his old iMac, so he tried Debian first (even though I told him not to) and thought Linux was still in the dark ages. Debian does not even attempt to be easy to use. Find a PC, or use a friends, and then try Redhat 8.1 when it comes out, that should give you a far more realistic impression. Stay away from any Mac distro! Debian is just hard, Yellow Dog suffers from having almost no users so they can't really keep up with the cutting edge like Redhat/SuSE can and Mandrake PPC is buggy as hell (or was whenever we tried it). If you do use a PPC distro, don't go around flaming Linux, and don't say you weren't warned.......
Performance of many basic tasks (window resizing etc.) is terrible due to client/server sync issues.
There are two separate issues here. The first is that a problem in the internal scheduler means that when performing opaque moves or resizes, some of the clients are starved of event processing time inside the X server, which is what makes it look like the contents of a window lag so far behind the border. That isn't X being "slow" as such, it's X being dumb about timeslice allocation. It's definately fixable, it just hasn't been fixed yet.
The second one is that window resizes are async, so the border updates separately to the contents. This has the advantage that if an app stops responding, you can still move/resize/minimize it, unlike in Windows where if an app freezes it gets nailed to the screen. The disadvantage is that the contents sometimes lag behind the borders in an opaque resize. In fact, with the dumb scheduler running, the lag is small - noticeable but small. XSync will probably go some way towards fixing this, given window managers and toolkits that support it, by letting the two clients lock themselves together.
Despite appearances, the X team are aware of the problems with the technology and the project and are addressing them slowly but surely.
Oh, and their website is XHTML by the way. It's simple so it can be navigated in text only browsers, and because time spent prettifying the site is better spent on the code. The GNU site is the same.
[i]The mouse pointers and fonts can be easily fixed if you know what you're doing. [/i]
That has ever been the bane of Linux and is partially why it is such a poor choice for the desktop
Please try not to make generalisations. Metatheming is well under way development wise, and XCursor themes are trivial to install. A gui for it in KDE/GNOME will be along shortly. By the way, for those who don't know, XCursor lets you use hardware accelerated 24bit alpha-blended animated icons. They are made out of PNG images, so expect to see lots of them on theming sites soon. Installing them is simply a matter of putting the.cur file into the right place on the disk and altering a config file - both things that are trivial for a GUI control panel applet to do. There isn't one yet, because XFree 4.3 hasn't been released yet. Give it a few months.
Typically installing software, doing updates, and so forth are *difficult*.
Yes, we know this, it's pointed out in every single discussion of Linux on the desktop ever. See my the link in my sig for possible solutions to it. People tend to generalise though "Oooh, it's hard to install software, therefore everything in Linux is hard". That just ain't so - one thing is hard. If there are other things that are hard, point them out, and they'll be made easy. There are only a few things left to polish up really, Linux is much closer than most people realise I think.
But is there any evidence to support that this is true for OS X alone? I think it is actually quite possible that Linux is already installed on more desktops than OS X.
More than possible, if you take figures from Apple (generous) and IDC (neutral) then Linux on the desktop has somewhere between double and 4x the number of users. The idea that OS X has more desktop users than Linux is a fallacy born of people making assumptions rather than looking at real world statistics.
No, this deal is completely clear before you start too - "Hi, this version is free. To upgrade to the new version will cost you a small fee"
Well some updates to the iApps were available for free if I remember correctly, hence the "switch" part of bait and switch.
Yes, and you are _free to ignore_ these upgrades if you want too, also.
Mmm, well possibly, but somewhere else in this thread somebody says that the iApps tend to be tied to certain versions of OS X, so if you upgrade the OS the old verions of the iApps might not work properly anymore. For instance, one iApp upgrade required 10.1
I insist that you give me a million dollars. I'm now pissed that you aren't doing it. I don't know nor care about business or economics or the fact that you don't have a spare million dollars.
That's different - giving stuff away isn't what Apple did, despite appearances. The iApps were only available as part of the Mac bundle, so the price was effectively included as part of the machine. It was effectively a trade, my money for your hardware/os/bundle of apps. Now the bundle of apps is being sold separately - it's like if you ordered a package of channels from Sky and suddenly half the channels turned into "premium" channels but the price of the package stayed the same. It's Skys right to do that, but the customers would be rather upset, they paid for something thinking it would continue to be what they paid for.
How is this any sort of bait and switch? It's a lot like shareware software that gives you a trial version with no expiration, but if you pay you can unlock the full features... which is what Apple has been doing with Quicktime vs. Quicktime Pro for years.
It's nothing like shareware. With shareware, the deal is perfectly clear before you start - the app is for trial purposes only, it will lock up or be restricted, you are expected to pay for it if you find it useful. Often with shareware in fact updates are/were thrown in for free or a much reduced price.
This is something that was given away for free, and no mention was ever made that future updates may cost money. Of course the possibility was always there, but as they were only available with Macs, I'd guess most people assumed the cost was a part of the hardware.
That's why it's called "bait and switch" - they switched their business model/ethics half way through.
And as for Microsoft not ever pulling this, what about Word 95, Word 96, Word 97, Word 98, Word 99, Word ME, Word 2000, Word 2001, Word XP, etc.
Again, not a useful comparison - Word has always been sold on the basis that there will be updates which you are free to ignore if you want. You don't have to use Office XP with Windows XP (although this might change) for instance. Microsofts model has been clear from day 1.
You complain about things getting EOL'd with every major upgrade, but you forget the primary Apple business model - they make money on hardware, not software. Most users get a Mac and stick with the operating system on it and never upgrade.
Apples business model is no excuse - if it pisses off the customers, who cares how Apple make money? Not the customers, that's for sure. I'd question the validity of the "never upgrade" statement, 10.0 and 10.1 in particular had severe performance problems and many/most/nearly all users have upgraded as far as I can see.
Additionally, the incremental upgrades of Mac OS are free - they only charge when it's a major change.
That depends on whether you consider 10.2 to be major enough to warrant $120. Considering that it was largely a collection of bugfixes/optimizations/slight UI polish, you could probably get the same with several MS service packs on 2K or NT (and of course, for free with linux).
Stop bitching 'cause you don't understand the business and think you should be given everything.
Understanding business has nothing to do with it - this guy was clearly a pretty loyal Apple user, who paid for.Mac yet he feels he's been screwed. He shouldn't have to "understand" Apples position: they are a company, they shouldn't need or deserve sympathy.
I think what people are pissed off about here is that it's yet another case of bait and switch, they give something away for "free" bundled with the Mac, people look at it as an advantage of the Mac platform, and effectively buy into it. Then the upgrades suddenly cost a lot more than they were expecting, so they feel cheated.
Now of course, it's entirely Apples perogative to start charging for their stuff. Nonetheless, if it's true considering that this is the second time now (third if you count 10.2) that they have suddenly introduced charges for stuff that people assumed would be free (.Mac anybody?), Jobs had better watch out - he'll get a reputation as somebody who pisses all over loyal customers time and time again.
Oh, and I'm sure there'll be a lot of posts saying "It's only X dollars, for what you get that's a bargain". They said that with 10.2, with.Mac and so on. Of course, value is in the eye of the beholder, but it seems to me at least that people are paying more and more for the Apple brand. The iApps are nice, but not that nice.
You want to search on the metadata? The Microsoft Indexing Server will build a database and let you search on it
Yes, but that functionality should really be in the FS itself, there's no reason to have external indexing services which will only get out of synch with what's on disk. NTFS is currently not capable of this, hence Storage+.
OLE Structured Storage is like a single file version of the filesystem we're talking about - a way of saving a bunch of objects (some of which you didn't create but that are in your document) into a file. I believe Microsoft's Office apps use it (could be wrong there though).
Correct, Office does indeed use it. OLE Structured Storage is a horrible system though, the internal objects are not only inaccessible to the filing system but the serialization mechanisms are a good example of how not to make an API - I believe they are also architecture dependant as well.
Right-click on an MP3 file and pick Properties in XP and go to the Summary tab.
Yes, but really the user should be the one adding metadata, not DLLs.
I don't really have a point to all this, just listing some stuff that Windows has that "should" make it easy for Microsoft to add the OO FS someday and have it instantly work with existing apps.
Not really, MS have been trying to get this for a long time now and never really succeeded. To their credit, it's bloody hard - the only OS that ever came close was BeFS with live queries, but the FS was so slow it dragged the whole system down, and even so it was a compromise on what they'd originally wanted.
Actually, I think Linux is in a far better position to take advantage of this kind of thing in the long term, because the open nature of most of the apps mean they can be upgraded relatively quickly. The movement is also not all that picky about breaking backwards compatability when need be either. When MS do come out with Storage+ (and i'm sure they will), it'll take years for the true implications to filter down through the developer chain. A real implementation of these ideas implies a rethink of the way computers work, nothing less would do.
BTW, the Linux answer to Storage+ is Reiser5, which I believe is the version that'll actually begin to make good on some of Hans Reisers promises (metadata as files, files as directories etc). Reiser3 and 4 are about laying the groundwork, in particular solving the performance issues that plagued BeOS. 5 and 6 should see the introduction of features that let you combine the best features of the HFS, relational and set theory models.
For those who are wondering, the author has updated the page linked to by the article with an answer to this point.
TheBrain: I just installed the beta version of this app. It looks great (and ready, too, something that newdocms isn't meant to be!), however, as far as I can tell (after using it very briefly) it neatly illustrates my point: this isn't integrated at the OS (GUI) level. To access a file through TheBrain, you need to go through the application: you can't simply fire up any Windows app and access your files directly, nor can you save your files into TheBrain if the application wasn't started from inside TheBrain. (Perhaps I am wrong -- as I said, I only had a very brief look at it.) That's precisely what I meant with the (admittedly poorly phrased) comment about the importance of free software: if you aren't free to modify the underlying system, you'll never get a chance to do it in a fully-integrated way.
Just how much could Microsoft force us to do using this tactic?
It couldn't force us to do anything, because as I pointed out above, Office already runs great on Linux thanks very much. No, they can't stymie Wine either, before anybody asks. It's legally solid, and clauses in the EULAS that state you can't use Wine to run it are also illegal - if they add such a clause (or already have one) you should feel free to ignore them, although IANAL etc.
Ditto for the rest of their software - it all revolves around Windows, and we have a 90% complete replacement for that in the form of Wine with Linux. Game over Gates. From now on, they'd better survive from writing good software, rather than relying on Windows to get them out of hot water.
. Hey, all one has to do is look at the profitability of the Macintosh Business unit at Microsoft which is doing quite nicely thank you, making software for a completely different platform than Windows. In fact, I find the Office X for OS X to be a superior product to the Windows version of Office given the tie-ins to OS X functionality and rendering.
Well, there are two separate issues here.
The first is that Microsoft most likely would not rewrite Office for Linux, ever. It simply costs too much. Office X by the way has not been very profitable, in fact, it may not even have been profitable at all, I seem to remember Microsoft bitching at Apple telling them to sell more copies of a competing OS just so they could make back what they spent on it.
It's also kind of a moot point, as Office already runs OK on Linux via Wine. If Microsoft wanted to "make" Office for Linux, all they'd need to do is ship binaries compiled with WineLib. A weeks work for one or two people, at most. Of course they'd probabably want to improve Wine if they were going to do that, which is fortunately now LGPLd.
In short, I think it'll be a cold day in hell before Microsoft release Office for Linux, but even if they don't, it doesn't matter, because you can just buy the Windows version and use that. Office X is certainly good, but it shows what Joel Spolski has been saying for some time, namely that rewrites rarely pay off. This all assumes MS can keep their lead on Office suites of course. OpenOffice isn't as good as MS Office yet, not by a long way (he says as OO segfaults on him yet again [sigh]), but Office hasn't really changed a great deal lately. It's not inconceivable that OO could catch up.
The main problem for Linux's wide acceptance is a congenital failure of the free software model, namely, that there is too much ego and not enough subservience to a standard
Hmm, and you think Windows development is an egoless place of peace and harmony where all 5000 developers agree and think in tune with each other? I can tell you, it's not. Ego abounds.
I have a Redhat/Gnome box. I daily suffer at least six different graphical file selection paradigms of various capabilities and presentations. One lets me scroll with the mouse wheel; another doesn't. One lists files in strict ASCII order; another ignores capitalization when sorting by name. And none approaches the ease and uniformity of the Windows standard.
6? I could probably get up to 3 if I tried hard and included really old apps like Motif Emacs (which you don't use file selectors in anyway) or RealPlayer. The GTK filepicker does suck, it's a known problem. When there is a better one, there will be 2 pickers, both of which are quite good. If somebody wanted to standardise common dialogs so KDE apps could be set to use GTK print/file dialogs and vice-versa, I guess that could be done, it's just a case of somebody sitting down and hammering out a spec.
But at least Microsoft has the luxury of dictating to their programmers that they SHALL adhere to a common look and feel.
Try telling that to the developers of Trillian, Roxio CD Creator, hell, even Office doesn't use the Windows look and feel. Apple is just as bad, they give their own apps completely made up UIs seemingly on a whim. QuickTime 4 had such an abomination for a GUI, that wasn't at all standard on any platform (not even the mac), it earned a place in the UI hall of shame. The idea that only Linux has fractured UI standards is a fallacy. It's a "problem" that affects all platforms, and really isn't all that much of a problem. The lightwave GUI is utterly non standard, but once you get used to it quite productive for instance. Better a productive GUI for a pro tool than a "standard" windows one that acts how you expect but is slow as molasses to use.
There's a line in one of the many HOW-TOs I've waded through that goes something like this:
I think what that means is that if you're an admin and you can't fix/understand this problem, you probably shouldn't be an admin. Arrogant attitude? Yeah, maybe. Probably true though.
I'd like to see distro folks get together and come up with one *common* meta-spec-file format that can contain all the metainformation that might need to be in a package. Then you can build any sort of packages from it. RPM's spec is a damn ugly, PITA-to-write, not-particularly-heavily-structured format, so it doesn't cut it.
Yeah, I did consider this. Unfortunately, they differ in very core ways - for instance package naming. Renaming all the redhat/debian packages to be the same would cause chaos - and whos name is better? You still have the limitations of RPM to deal with of course.
Yup. Why, if I didn't know better, I'd be almost willing to say that Stallman designed things to be inconvenient for non-source distributed software.;-)
LOL! I have thought exactly the same thing. Well, in this case Stallman didn't write the part of glibc that causes problems, but still.... I wonder:)
It'd be nice to support (if not in the package manager itself, in a front end to it) automatic downloading a la emerge or apt-get that's aware of mirrors
Check
It'd be nice to use gpg for *everything* (including downloading new mirror lists), and do so transparently to the user.
We're still debating this. It implies a central authority with absolute control and infallibility for one. Maybe so, maybe no. We're not at the stage where it could be implemented anyway.
It'd be nice to have the package manager have an absolutely minimal set of requirements (python and perl are right out).
Just bash. Check
It'd be nice to have the package manager have the ability to *configure* software...to understand configure options. That would be decidedly cool.
Well, at the moment we build binary.packages from the source tree directly, but I want to introduce a.src.package stage first that can then be automatically converted to binary packages for different architectures. Understanding configure options might become a part of that.
It'd be nice for the package manager to run as non-root
Check (though for security reasons you still need to set autopackage up the first time as root). After that you can install packages to your home dir without root access.
and to allow finding "differences" between two system states -- RH might define "RH 8 is set of packages foo with these specified SHAsums".
That's something for RPM to deal with. We don't replace it, just compliment it.
It'd nice fo rthe package manager to have decent backward compatibility (unlike every *other* GNU tool that starts with "auto":-( )
Well, once we reach 1.0 the goal is to maintain interface compatability for as long as possible. We have mechanisms in place to support that already, but we're a long way from 1.0. We'll only release it when we're sure it's solid. But we can't predict the future.....
It'd be nice for the package manager to support "user overrides", where the user *knows* something is fulfilled and doesn't want to hear about it again (for example, if he's using a non-packaged kernel).
Yeah, well we check the system directly (not using the rpm database) so in theory you should never need to override it's decisions because it'll always pick up the actual state of the system. Of course, that assumes packagers are infallible:)
BTW, if you wrote the blurb on package management on autopackage.org, that's one of the best discussions of package management and issues with current systems I've ever read.
Most Linux software can be easily ported to other forms of Unix, normally FreeBSD and Solaris. If you look at what the developers themselves use though, you normally find it's Linux all the way - there is 1 person working on keeping the FreeBSD port of Wine up to speed, and I believe it requires parts of the Linux emulation to work (I might be wrong).
Really, it seems that FreeBSD in particular is mostly being dragged along by Linux - despite FreeBSD being supposedly more commercially friendly, if you look at the commercial developers for say GNOME, you see they are all Linux companies. Ximian in particular don't release FreeBSD binaries as far as I'm aware, and of course you have RedHat, SuSE, CodeFactory etc.
As an aside, late this year should hopefully see Wine 0.9 which is the release scheduled to get ease of use. Let's hope so, eh?
What can we look forward to this year? Off the top of my head:
XFree 4.3 - featuring 24bit with alpha channel animated cursors, expect to see lots of cool themed cursors on the X11 theming sites. New in this release also is the R&R extension, allowing on the fly resolution switching. No, we don't have transparent windows in this release, this currently is being held back by performance issues and internal rearchitecting. Nonetheless, everybody likes eyecandy, and this release will satiate our appetites at least for now.
GNOME2.2: Lots of goodies in this release, including Fontilus (drag and drop font installation/preview), a Network Neighbourhood style view, more font config options (as seen in redhat8), unified theming system, startup notification (but done properly this time), and more. It also features....
GStreamer! Now with KDE bindings too, hopefully 2003 will be the year that Linux multimedia gets started. Although still some way from 1.0, some parts of the gnome2.2 desktop will be using GStreamer. Just bear in mind if you write apps that use it - it's not API stable yet. In particular, it'll be boosted by....
ALSA, which sports better support for sound cards and a cleaner architecture, as well as a whole host of other cool things. If only somebody would get off their ass and write a mixer/resampler server shim between libasound and the kernel, the message "another program is using this device" could be banished forever. But as far as I know nobody has picked up the gauntlet. ALSA is of course part of.....
Linux 2.6 which will be released sometime in June/July apparently. Some key desktop enhancements in this, including low latency and preempt, which is a step forward for desktop responsiveness. Think: it always feels like there's no CPU load. Kind of.
KDE 3.1 (I hadn't forgotten;) which other than being a lot more secure now, sports tabs in Konqueror, better support for freedesktop.org standards, new default (pretty) artwork, folder icons that represent the folders contents, desktop sharing built in and a whole load more
The Gimp 1.4 - much better looking now, with revamped user interface, better text support, a vector tool, named cut/copy buffers and support for more plugin langauges.
More usability work both in and out of the desktop efforts. Expect to see the HIG mature and lots more apps become compliant, already non-GNOME apps like Gaim and XChat are getting higified (if you try their devel versions you'll see what I mean).
Okay, I'm not going to say things are perfect, but I'm sitting here with a RH 8.0-based box with apt-get.
You just described the ideal scenario, one that unfortunately doesn't happen very often. In particular, the number of RPMs available via apt4rpm on RH8 is incredibly small. When apt works, it works great, hence the fact that we're stealing from it liberally in autopackage. Usually though, it doesn't work, unless you use Debian, and then the inertia that attempting to package nearly every piece of software on the planet implies (gentoo are having problems with this too) means packages are often out of date.
The Windows scenario as described is also sort of unusual, although as Windows software installation was grown rather than designed yes, it too is far from perfect.
What's needed is for developers to be able to produce portable binary packages, and then have a distributed and decentralised DNS style network to replace apt. The interface is still the same: "package install galeon" and wait, but unlike apt it scales.
Of course, that makes it sound easy. It isn't. For instance, the GNU ld.so (dynamic linker) contains design, ah, issues which make producing portable binaries quite hard (to do with link trees). We're figuring out what to do about that now, talking to libc-alpha, distros etc. We may (worst case scenario) end up having to distribute our own linker, luckily ELF allows for plug and play linkers.
Then you've got the myriad differences between distros. Every distro except debian uses the FSF version of install-info. Debian based distros use their own, slightly incompatable version. File locations differ and most packages built with automake are not relocatable. We have solutions for those things too.
OK, end rant. It's going to be a long haul, but believe me, we will end up with the most kickass software management system in the world. It'll be like apt, except it works more often (hopefully one day, always works), and it'll look good too. Will we make v1.0 in 2003? Hmmm, maybe so, maybe no. We'll have to wait and see. If not 2003 then definately 2004.
I hate to throw unchecked stats around, but even if this is remotely the case, then opensource companies have a long fight ahead of them.
I think we all knew that. What amazes me is just how frigging many of them there are. There's no way the market can support as many commercial distros as there currently are.
I'll stick my head out and predict that 2003 will see the herd thinned somewhat: I can't see a good future for Mandrake (as a company). Out of Lindows, Lycoris and Xandros, only one will remain (I'd bet Xandros). Geographical dominance will continue to be the name of the game, with Redhat taking America and parts of Europe, and SuSE taking Europe and parts of America, Conectiva in Latin America etc.
On the other hand, those that remain will be stronger, which can't be a bad thing. RedHat will start making money reliably I hope - their standing themselves in good stead for taking over the corporate desktop at this rate.
Hmm, while I've got the post comment page open, I'd just like to throw in some anecdotal evidence of my own. I started using Linux in early January of last year, so I've seen exactly a year pass in Linuxland. The progress I've seen is unbelievable: Linux got pretty artwork, got usability, speed, good fonts, a good office suite, a good web browser (moz1.0), KDE3, GNOME2 (and GTK2) and an easy to use "just works" version of Wine came out (no, really!), and finally I started my own project [grin]
It'll be fascinating to see where 2003 gets us. Look out Microsoft!
The hardest part is really translating correctly the text, taking into account the particularities of every language, the customs,... and obviously, keeping the translated version up to date.
Amen to that. A friend of mine who develops the rather fine Rhymbox Jabber client for Windows recently decided to try out Redhat 8, and one of the things he noticed was that the quality of the translations was not good (he is dutch). In particular, although GTK had been translated so the buttons were in Dutch, the Anaconda texts had not been, giving a jarring effect. He said the translations were also not very high quality - although I hadn't really suspected it before, just like art and code, there are good translators and not so good translators (apparently).
What is really, really needed, at least in the open source community, is a centralised translations centre, where free software projects can upload their.pot files for translation, and teams of translators organised by language pick strings out of the database and translate them. Sort of the equivalent of the LDP or kde-look.org. By combining all the translation teams together, it's easier for new translators to get on board, it's easier for instructional material on how to make good translations to be distributed, and hopefully speed and accuracy of translations should go up.
The windows compatible iPod is simply an iPod with a FAT32 harddisk iirc, they didn't release any official Windows software for it, nor do they support it.
HFS is not what was reverese engineered, the on disk catalog format was not documented. You can't just add an MP3 to the iPod disk, you have to update the database as well.
If you ignore the fact that you can recompile the kernel and change most OS variables using XML plists and NetInfo, you are absolutely correct. If I ignore my need for oxygen I can breathe in space too.
plists and NetInfo are hardly customization tools. They are minor tweaks at best. Even the Windows registry does much better than that, and of course this is nothing compared to what can be tweaked if you have the source, or can replace layers of the OS at will.
There was a time, not long ago, where Apple made interesting, even innovative technology--but designed it so it worked only with its Macintosh hardware.
So.... just like the iPod then, which works on other platforms only due to 3rd parties reverse engineering parts of the on disk format?
It's great for the industry and many others that Apple is slowly crawling out of the mindset that all of their products must work strictly with a Mac
No it isn't. Otherwise why are Apple buying up app vendors (I don't recall the name of the product i'm thinking of, some graphics/music program), and scaring all the customers silly because they think Apple will make them Mac only?
Their move to Mac OS X would be contradictory to such a philosophy since *nix is a widely supported and tinkerable OS.
Except OS X isn't tinkerable at all. Practically all the code Apple has written is closed source, and the Mac parts of MacOS are generally only capable of doing things one way. Unlike every Linux and Windows, MacOS is still not capable of being themed by 3rd parties (unless you consider a grey version of the default a "theme").
*chuckle*:) Well, I don't tend to use Python much, Ruby is starting to look good though. A cross between Python, Perl and Smalltalk with gnome2 bindings? Mmm, I think so. But I'll wait until it's more mature (and I actually need it) before playing with it. And with semicolons!
The funny thing is that your kind is outnumbered 100 to 1. 99% of the graphics population find would find GIMP counter-intuitive.
Yes, but the GIMP isn't just used by the Photoshop using graphics population.
The vast majority of computer users will, at some point, probably need to do something with images. Whether it's just convert between different formats, resize them, retouch a photo, eliminate the background of an image, whatever, the GIMP can do all those things. I find the GIMP easier to work with than Photoshop, it's just familiarity. I certainly am not spending all that money on PS, I'm not a graphics pro, I don't need to work in exotic colourspaces, I, like 99% of the world, just need something that'll work well for me.
So, that's who can benefit from the gimp. Beating Photoshop seems to be an implied goal of the GIMP, but it isn't really. We all use it at work for instance, because our graphics work is limited to web design and stuff for presentations, we're not professional artists. The Gimp is great for that stuff.
Slashdot Mirror
tia -mike
Yeah, most commercial operating systems don't deal with dependancies. I can understand why, it's bloody difficult. Bear in mind large amounts of code sharing which is the de facto standard on Linux simply does not exist on other operating systems, although Windows gets the closest with COM. There is practically no code sharing on OS X, OmniNetwork or whatever it's called is the only example I can think of. The type of dep management we need on Linux would be overkill for them, it's easiest to statically link, despite the well known problems with that approach.
Note that despite the whinging you'll find here on slashdot, Linux cannot, will never be like MacOS or Windows. Linux systems are best visualised as floating pools of components - the flexibility that comes with freedom and openness means you can't make many assumptions about the system. For instance, all installations of Windows and OS X have a graphics layer, a widget toolkit etc. They cannot be turned off. For servers, this is just bloat, which is why it's optional in Linux, but that also means you can't assume there is graphics support when you install an app. Equally, there is healthy competition between frameworks and APIs and due the way Linux is developed (more like grown), you can never assume the API/runtime you want to use is present.
Therefore dep management is essential, absolutely critical for maintaining the freedom and flexibility that Linux is famed for. Yes, it's hard, but hey, the end result will kick ass. Oh BTW the "large hard disk" excuse is getting old - that's the sort of thing poor engineers have said since the beginning of time to excuse inefficiency and it usually covers up deeper problems (static linking is also insecure and wastes memory, normally a far more pressing problem than disk space).
I've seen this before, a Mac user friend wanted to look into Linux because OS X was so slow on his old iMac, so he tried Debian first (even though I told him not to) and thought Linux was still in the dark ages. Debian does not even attempt to be easy to use. Find a PC, or use a friends, and then try Redhat 8.1 when it comes out, that should give you a far more realistic impression. Stay away from any Mac distro! Debian is just hard, Yellow Dog suffers from having almost no users so they can't really keep up with the cutting edge like Redhat/SuSE can and Mandrake PPC is buggy as hell (or was whenever we tried it). If you do use a PPC distro, don't go around flaming Linux, and don't say you weren't warned.......
There are two separate issues here. The first is that a problem in the internal scheduler means that when performing opaque moves or resizes, some of the clients are starved of event processing time inside the X server, which is what makes it look like the contents of a window lag so far behind the border. That isn't X being "slow" as such, it's X being dumb about timeslice allocation. It's definately fixable, it just hasn't been fixed yet.
The second one is that window resizes are async, so the border updates separately to the contents. This has the advantage that if an app stops responding, you can still move/resize/minimize it, unlike in Windows where if an app freezes it gets nailed to the screen. The disadvantage is that the contents sometimes lag behind the borders in an opaque resize. In fact, with the dumb scheduler running, the lag is small - noticeable but small. XSync will probably go some way towards fixing this, given window managers and toolkits that support it, by letting the two clients lock themselves together.
Despite appearances, the X team are aware of the problems with the technology and the project and are addressing them slowly but surely.
Oh, and their website is XHTML by the way. It's simple so it can be navigated in text only browsers, and because time spent prettifying the site is better spent on the code. The GNU site is the same.
That has ever been the bane of Linux and is partially why it is such a poor choice for the desktop
Please try not to make generalisations. Metatheming is well under way development wise, and XCursor themes are trivial to install. A gui for it in KDE/GNOME will be along shortly. By the way, for those who don't know, XCursor lets you use hardware accelerated 24bit alpha-blended animated icons. They are made out of PNG images, so expect to see lots of them on theming sites soon. Installing them is simply a matter of putting the .cur file into the right place on the disk and altering a config file - both things that are trivial for a GUI control panel applet to do. There isn't one yet, because XFree 4.3 hasn't been released yet. Give it a few months.
Typically installing software, doing updates, and so forth are *difficult*.
Yes, we know this, it's pointed out in every single discussion of Linux on the desktop ever. See my the link in my sig for possible solutions to it. People tend to generalise though "Oooh, it's hard to install software, therefore everything in Linux is hard". That just ain't so - one thing is hard. If there are other things that are hard, point them out, and they'll be made easy. There are only a few things left to polish up really, Linux is much closer than most people realise I think.
More than possible, if you take figures from Apple (generous) and IDC (neutral) then Linux on the desktop has somewhere between double and 4x the number of users. The idea that OS X has more desktop users than Linux is a fallacy born of people making assumptions rather than looking at real world statistics.
Well some updates to the iApps were available for free if I remember correctly, hence the "switch" part of bait and switch.
Yes, and you are _free to ignore_ these upgrades if you want too, also.
Mmm, well possibly, but somewhere else in this thread somebody says that the iApps tend to be tied to certain versions of OS X, so if you upgrade the OS the old verions of the iApps might not work properly anymore. For instance, one iApp upgrade required 10.1
I insist that you give me a million dollars. I'm now pissed that you aren't doing it. I don't know nor care about business or economics or the fact that you don't have a spare million dollars.
That's different - giving stuff away isn't what Apple did, despite appearances. The iApps were only available as part of the Mac bundle, so the price was effectively included as part of the machine. It was effectively a trade, my money for your hardware/os/bundle of apps. Now the bundle of apps is being sold separately - it's like if you ordered a package of channels from Sky and suddenly half the channels turned into "premium" channels but the price of the package stayed the same. It's Skys right to do that, but the customers would be rather upset, they paid for something thinking it would continue to be what they paid for.
It's nothing like shareware. With shareware, the deal is perfectly clear before you start - the app is for trial purposes only, it will lock up or be restricted, you are expected to pay for it if you find it useful. Often with shareware in fact updates are/were thrown in for free or a much reduced price.
This is something that was given away for free, and no mention was ever made that future updates may cost money. Of course the possibility was always there, but as they were only available with Macs, I'd guess most people assumed the cost was a part of the hardware.
That's why it's called "bait and switch" - they switched their business model/ethics half way through.
And as for Microsoft not ever pulling this, what about Word 95, Word 96, Word 97, Word 98, Word 99, Word ME, Word 2000, Word 2001, Word XP, etc.
Again, not a useful comparison - Word has always been sold on the basis that there will be updates which you are free to ignore if you want. You don't have to use Office XP with Windows XP (although this might change) for instance. Microsofts model has been clear from day 1.
You complain about things getting EOL'd with every major upgrade, but you forget the primary Apple business model - they make money on hardware, not software. Most users get a Mac and stick with the operating system on it and never upgrade.
Apples business model is no excuse - if it pisses off the customers, who cares how Apple make money? Not the customers, that's for sure. I'd question the validity of the "never upgrade" statement, 10.0 and 10.1 in particular had severe performance problems and many/most/nearly all users have upgraded as far as I can see.
Additionally, the incremental upgrades of Mac OS are free - they only charge when it's a major change.
That depends on whether you consider 10.2 to be major enough to warrant $120. Considering that it was largely a collection of bugfixes/optimizations/slight UI polish, you could probably get the same with several MS service packs on 2K or NT (and of course, for free with linux).
Stop bitching 'cause you don't understand the business and think you should be given everything.
Understanding business has nothing to do with it - this guy was clearly a pretty loyal Apple user, who paid for .Mac yet he feels he's been screwed. He shouldn't have to "understand" Apples position: they are a company, they shouldn't need or deserve sympathy.
Now of course, it's entirely Apples perogative to start charging for their stuff. Nonetheless, if it's true considering that this is the second time now (third if you count 10.2) that they have suddenly introduced charges for stuff that people assumed would be free (.Mac anybody?), Jobs had better watch out - he'll get a reputation as somebody who pisses all over loyal customers time and time again.
Oh, and I'm sure there'll be a lot of posts saying "It's only X dollars, for what you get that's a bargain". They said that with 10.2, with .Mac and so on. Of course, value is in the eye of the beholder, but it seems to me at least that people are paying more and more for the Apple brand. The iApps are nice, but not that nice.
Yes, but that functionality should really be in the FS itself, there's no reason to have external indexing services which will only get out of synch with what's on disk. NTFS is currently not capable of this, hence Storage+.
OLE Structured Storage is like a single file version of the filesystem we're talking about - a way of saving a bunch of objects (some of which you didn't create but that are in your document) into a file. I believe Microsoft's Office apps use it (could be wrong there though).
Correct, Office does indeed use it. OLE Structured Storage is a horrible system though, the internal objects are not only inaccessible to the filing system but the serialization mechanisms are a good example of how not to make an API - I believe they are also architecture dependant as well.
Right-click on an MP3 file and pick Properties in XP and go to the Summary tab.
Yes, but really the user should be the one adding metadata, not DLLs.
I don't really have a point to all this, just listing some stuff that Windows has that "should" make it easy for Microsoft to add the OO FS someday and have it instantly work with existing apps.
Not really, MS have been trying to get this for a long time now and never really succeeded. To their credit, it's bloody hard - the only OS that ever came close was BeFS with live queries, but the FS was so slow it dragged the whole system down, and even so it was a compromise on what they'd originally wanted.
Actually, I think Linux is in a far better position to take advantage of this kind of thing in the long term, because the open nature of most of the apps mean they can be upgraded relatively quickly. The movement is also not all that picky about breaking backwards compatability when need be either. When MS do come out with Storage+ (and i'm sure they will), it'll take years for the true implications to filter down through the developer chain. A real implementation of these ideas implies a rethink of the way computers work, nothing less would do.
BTW, the Linux answer to Storage+ is Reiser5, which I believe is the version that'll actually begin to make good on some of Hans Reisers promises (metadata as files, files as directories etc). Reiser3 and 4 are about laying the groundwork, in particular solving the performance issues that plagued BeOS. 5 and 6 should see the introduction of features that let you combine the best features of the HFS, relational and set theory models.
It couldn't force us to do anything, because as I pointed out above, Office already runs great on Linux thanks very much. No, they can't stymie Wine either, before anybody asks. It's legally solid, and clauses in the EULAS that state you can't use Wine to run it are also illegal - if they add such a clause (or already have one) you should feel free to ignore them, although IANAL etc.
Ditto for the rest of their software - it all revolves around Windows, and we have a 90% complete replacement for that in the form of Wine with Linux. Game over Gates. From now on, they'd better survive from writing good software, rather than relying on Windows to get them out of hot water.
Well, there are two separate issues here.
The first is that Microsoft most likely would not rewrite Office for Linux, ever. It simply costs too much. Office X by the way has not been very profitable, in fact, it may not even have been profitable at all, I seem to remember Microsoft bitching at Apple telling them to sell more copies of a competing OS just so they could make back what they spent on it.
It's also kind of a moot point, as Office already runs OK on Linux via Wine. If Microsoft wanted to "make" Office for Linux, all they'd need to do is ship binaries compiled with WineLib. A weeks work for one or two people, at most. Of course they'd probabably want to improve Wine if they were going to do that, which is fortunately now LGPLd.
In short, I think it'll be a cold day in hell before Microsoft release Office for Linux, but even if they don't, it doesn't matter, because you can just buy the Windows version and use that. Office X is certainly good, but it shows what Joel Spolski has been saying for some time, namely that rewrites rarely pay off. This all assumes MS can keep their lead on Office suites of course. OpenOffice isn't as good as MS Office yet, not by a long way (he says as OO segfaults on him yet again [sigh]), but Office hasn't really changed a great deal lately. It's not inconceivable that OO could catch up.
Hmm, and you think Windows development is an egoless place of peace and harmony where all 5000 developers agree and think in tune with each other? I can tell you, it's not. Ego abounds.
I have a Redhat/Gnome box. I daily suffer at least six different graphical file selection paradigms of various capabilities and presentations. One lets me scroll with the mouse wheel; another doesn't. One lists files in strict ASCII order; another ignores capitalization when sorting by name. And none approaches the ease and uniformity of the Windows standard.
6? I could probably get up to 3 if I tried hard and included really old apps like Motif Emacs (which you don't use file selectors in anyway) or RealPlayer. The GTK filepicker does suck, it's a known problem. When there is a better one, there will be 2 pickers, both of which are quite good. If somebody wanted to standardise common dialogs so KDE apps could be set to use GTK print/file dialogs and vice-versa, I guess that could be done, it's just a case of somebody sitting down and hammering out a spec.
But at least Microsoft has the luxury of dictating to their programmers that they SHALL adhere to a common look and feel.
Try telling that to the developers of Trillian, Roxio CD Creator, hell, even Office doesn't use the Windows look and feel. Apple is just as bad, they give their own apps completely made up UIs seemingly on a whim. QuickTime 4 had such an abomination for a GUI, that wasn't at all standard on any platform (not even the mac), it earned a place in the UI hall of shame. The idea that only Linux has fractured UI standards is a fallacy. It's a "problem" that affects all platforms, and really isn't all that much of a problem. The lightwave GUI is utterly non standard, but once you get used to it quite productive for instance. Better a productive GUI for a pro tool than a "standard" windows one that acts how you expect but is slow as molasses to use.
There's a line in one of the many HOW-TOs I've waded through that goes something like this:
I think what that means is that if you're an admin and you can't fix/understand this problem, you probably shouldn't be an admin. Arrogant attitude? Yeah, maybe. Probably true though.
Yeah, I did consider this. Unfortunately, they differ in very core ways - for instance package naming. Renaming all the redhat/debian packages to be the same would cause chaos - and whos name is better? You still have the limitations of RPM to deal with of course.
Yup. Why, if I didn't know better, I'd be almost willing to say that Stallman designed things to be inconvenient for non-source distributed software. ;-)
LOL! I have thought exactly the same thing. Well, in this case Stallman didn't write the part of glibc that causes problems, but still.... I wonder :)
It'd be nice to support (if not in the package manager itself, in a front end to it) automatic downloading a la emerge or apt-get that's aware of mirrors
Check
It'd be nice to use gpg for *everything* (including downloading new mirror lists), and do so transparently to the user.
We're still debating this. It implies a central authority with absolute control and infallibility for one. Maybe so, maybe no. We're not at the stage where it could be implemented anyway.
It'd be nice to have the package manager have an absolutely minimal set of requirements (python and perl are right out).
Just bash. Check
It'd be nice to have the package manager have the ability to *configure* software...to understand configure options. That would be decidedly cool.
Well, at the moment we build binary .packages from the source tree directly, but I want to introduce a .src.package stage first that can then be automatically converted to binary packages for different architectures. Understanding configure options might become a part of that.
It'd be nice for the package manager to run as non-root
Check (though for security reasons you still need to set autopackage up the first time as root). After that you can install packages to your home dir without root access.
and to allow finding "differences" between two system states -- RH might define "RH 8 is set of packages foo with these specified SHAsums".
That's something for RPM to deal with. We don't replace it, just compliment it.
It'd nice fo rthe package manager to have decent backward compatibility (unlike every *other* GNU tool that starts with "auto" :-( )
Well, once we reach 1.0 the goal is to maintain interface compatability for as long as possible. We have mechanisms in place to support that already, but we're a long way from 1.0. We'll only release it when we're sure it's solid. But we can't predict the future.....
It'd be nice for the package manager to support "user overrides", where the user *knows* something is fulfilled and doesn't want to hear about it again (for example, if he's using a non-packaged kernel).
Yeah, well we check the system directly (not using the rpm database) so in theory you should never need to override it's decisions because it'll always pick up the actual state of the system. Of course, that assumes packagers are infallible :)
BTW, if you wrote the blurb on package management on autopackage.org, that's one of the best discussions of package management and issues with current systems I've ever read.
Yes I did, thanks.
Really, it seems that FreeBSD in particular is mostly being dragged along by Linux - despite FreeBSD being supposedly more commercially friendly, if you look at the commercial developers for say GNOME, you see they are all Linux companies. Ximian in particular don't release FreeBSD binaries as far as I'm aware, and of course you have RedHat, SuSE, CodeFactory etc.
As an aside, late this year should hopefully see Wine 0.9 which is the release scheduled to get ease of use. Let's hope so, eh?
What can we look forward to this year? Off the top of my head:
Mmmm, toys :)
You just described the ideal scenario, one that unfortunately doesn't happen very often. In particular, the number of RPMs available via apt4rpm on RH8 is incredibly small. When apt works, it works great, hence the fact that we're stealing from it liberally in autopackage. Usually though, it doesn't work, unless you use Debian, and then the inertia that attempting to package nearly every piece of software on the planet implies (gentoo are having problems with this too) means packages are often out of date.
The Windows scenario as described is also sort of unusual, although as Windows software installation was grown rather than designed yes, it too is far from perfect.
What's needed is for developers to be able to produce portable binary packages, and then have a distributed and decentralised DNS style network to replace apt. The interface is still the same: "package install galeon" and wait, but unlike apt it scales.
Of course, that makes it sound easy. It isn't. For instance, the GNU ld.so (dynamic linker) contains design, ah, issues which make producing portable binaries quite hard (to do with link trees). We're figuring out what to do about that now, talking to libc-alpha, distros etc. We may (worst case scenario) end up having to distribute our own linker, luckily ELF allows for plug and play linkers.
Then you've got the myriad differences between distros. Every distro except debian uses the FSF version of install-info. Debian based distros use their own, slightly incompatable version. File locations differ and most packages built with automake are not relocatable. We have solutions for those things too.
OK, end rant. It's going to be a long haul, but believe me, we will end up with the most kickass software management system in the world. It'll be like apt, except it works more often (hopefully one day, always works), and it'll look good too. Will we make v1.0 in 2003? Hmmm, maybe so, maybe no. We'll have to wait and see. If not 2003 then definately 2004.
I think we all knew that. What amazes me is just how frigging many of them there are. There's no way the market can support as many commercial distros as there currently are.
I'll stick my head out and predict that 2003 will see the herd thinned somewhat: I can't see a good future for Mandrake (as a company). Out of Lindows, Lycoris and Xandros, only one will remain (I'd bet Xandros). Geographical dominance will continue to be the name of the game, with Redhat taking America and parts of Europe, and SuSE taking Europe and parts of America, Conectiva in Latin America etc.
On the other hand, those that remain will be stronger, which can't be a bad thing. RedHat will start making money reliably I hope - their standing themselves in good stead for taking over the corporate desktop at this rate.
Hmm, while I've got the post comment page open, I'd just like to throw in some anecdotal evidence of my own. I started using Linux in early January of last year, so I've seen exactly a year pass in Linuxland. The progress I've seen is unbelievable: Linux got pretty artwork, got usability, speed, good fonts, a good office suite, a good web browser (moz1.0), KDE3, GNOME2 (and GTK2) and an easy to use "just works" version of Wine came out (no, really!), and finally I started my own project [grin]
It'll be fascinating to see where 2003 gets us. Look out Microsoft!
Amen to that. A friend of mine who develops the rather fine Rhymbox Jabber client for Windows recently decided to try out Redhat 8, and one of the things he noticed was that the quality of the translations was not good (he is dutch). In particular, although GTK had been translated so the buttons were in Dutch, the Anaconda texts had not been, giving a jarring effect. He said the translations were also not very high quality - although I hadn't really suspected it before, just like art and code, there are good translators and not so good translators (apparently).
What is really, really needed, at least in the open source community, is a centralised translations centre, where free software projects can upload their .pot files for translation, and teams of translators organised by language pick strings out of the database and translate them. Sort of the equivalent of the LDP or kde-look.org. By combining all the translation teams together, it's easier for new translators to get on board, it's easier for instructional material on how to make good translations to be distributed, and hopefully speed and accuracy of translations should go up.
No, I don't have time to do such a site. Anybody?
HFS is not what was reverese engineered, the on disk catalog format was not documented. You can't just add an MP3 to the iPod disk, you have to update the database as well.
If you ignore the fact that you can recompile the kernel and change most OS variables using XML plists and NetInfo, you are absolutely correct. If I ignore my need for oxygen I can breathe in space too.
plists and NetInfo are hardly customization tools. They are minor tweaks at best. Even the Windows registry does much better than that, and of course this is nothing compared to what can be tweaked if you have the source, or can replace layers of the OS at will.
You can find more instructions (a non-slashdotted copy) here
So.... just like the iPod then, which works on other platforms only due to 3rd parties reverse engineering parts of the on disk format?
It's great for the industry and many others that Apple is slowly crawling out of the mindset that all of their products must work strictly with a Mac
No it isn't. Otherwise why are Apple buying up app vendors (I don't recall the name of the product i'm thinking of, some graphics/music program), and scaring all the customers silly because they think Apple will make them Mac only?
Their move to Mac OS X would be contradictory to such a philosophy since *nix is a widely supported and tinkerable OS.
Except OS X isn't tinkerable at all. Practically all the code Apple has written is closed source, and the Mac parts of MacOS are generally only capable of doing things one way. Unlike every Linux and Windows, MacOS is still not capable of being themed by 3rd parties (unless you consider a grey version of the default a "theme").
*chuckle* :) Well, I don't tend to use Python much, Ruby is starting to look good though. A cross between Python, Perl and Smalltalk with gnome2 bindings? Mmm, I think so. But I'll wait until it's more mature (and I actually need it) before playing with it. And with semicolons!
Yes, but the GIMP isn't just used by the Photoshop using graphics population.
The vast majority of computer users will, at some point, probably need to do something with images. Whether it's just convert between different formats, resize them, retouch a photo, eliminate the background of an image, whatever, the GIMP can do all those things. I find the GIMP easier to work with than Photoshop, it's just familiarity. I certainly am not spending all that money on PS, I'm not a graphics pro, I don't need to work in exotic colourspaces, I, like 99% of the world, just need something that'll work well for me.
So, that's who can benefit from the gimp. Beating Photoshop seems to be an implied goal of the GIMP, but it isn't really. We all use it at work for instance, because our graphics work is limited to web design and stuff for presentations, we're not professional artists. The Gimp is great for that stuff.