I found this interesting, as i had heard that the bulk of the linux distributions had not yet managed to migrate to GCC 3. Neat to see Apple is staying on top of this whole UNIX-technology thing:)
Hardly. Most distros and projects have experimented with the GCC 3 series, but it's not yet good enough. For instance, although KDE actually compiles with it now, it takes twice as long, and produces slower code as well. That's why they're not using it.
Maybe these bugs don't exist in the Objective-C parts of it, I don't know. But using the latest GCC when it's not yet actually better than the previous is hardly "keeping on top of UNIX technology"
Good idea. I've been thinking that this'd be a good idea for a while actually, but it should be more general, ie programs can link to libtutorial library and have an easy way of making interactive tutorials that integrate with their software. Not just tutorials for the desktop environments, but also for the GIMP, OpenOffice etc. It'd save reinventing the wheel.
I don't have time right now, I'm too busy working on autopackage, but is anybody else interested?
Hmmm, okay, I hear you about the groups thing. So do you think there would be a lot of people who are switched off by the use of the word "revolution"?
OK, so some people would say "for crying out loud, it's just an operating system", but for others they might be interested in the story behind it. Think about it - the history of Linux is a great story, and more to the point, it's a human interest story. Of course I don't think the revolution idea would be good at all for actually selling Linux, but for raising awareness I think it might do the trick. You can always tailor the marketing for specific groups of people (server admins, home desktop users etc) later.
The idea that Microsoft is paranoid and fearing Linux might be true, but is totally overblown. Microsoft fears any competition, the most likely competitor is Apple more than Linux.
I don't think this is right. Windows is hated not because it's dominant per se, in fact many people like it's dominance as it means easier to learn computers - what people hate is the feeling that they have no choice, that they MUST put up with the general poorness of Windows/Office. That wouldn't apply with Linux. Look how many distros there are already, and how different they are.
What goals does the Linux community have, other than supplanting Windows?
Well, my goal is to ensure the dominance of open platforms. Too much damage is done by closed platforms, and as I am going to spend most of the rest of my life in the computer industry, I want to ensure we have a stable foundation to go from.
Nice points. However, surely you overlook the fact that awareness of Linux amongst the general public is extremely low?
I don't think advertising would be bad per se, as long as it was done right. I think most "computer people" now know at least what Linux is, if not much about it. So what's needed (but not yet, linux isn't ready for home desktops yet) is advertising that plants the seeds of curiousity in peoples minds - that gets them asking "What is Linux?". They can then ask their local geek, who will (hopefully) expound upon them it's greatness (the excuse being, they did ask;)
You say you have a marketing background. So what do you think of this? Let's say we have a hypothetical campaign. Like most stuff to do with linux, it doesn't have much money, let's say we rule out TV advertising. So we need to get far more awareness for each pound, dollar, euro we spend than other campaigns.
Linux came from the streets. It's not like other products. Therefore, we can get away with a different sort of advertising. We can play upon the "revolutionary" aspects of it. Let's say, for a month or two, in the major cities of the world some billboard space is bought up, and filled with simple posters that have a faded picture of tux, with slogans such as "Get Ready", "Join the revolution" or "Power to the People" overlayed. Perhaps one or two have the word "Linux" underneath, so people know what to ask about, what to call it.
IBM had a neat idea - people associate "revolution from the streets" with graffiti. It doesn't have to be illegal, if you as a landlord had a spare wall lying around, wouldn't you jump at a chance to earn a bit of money from it by letting these friendly guys spray paint some words on the side? As long as they clean up afterwards.....
The aim would be to raise lots of awareness rather than promote the product which is hard to get across in adverts anyway (distro? what's a distro?). That vague awareness could then be turned into enthusiasm by word of mouth from geeks and other happy users. It'd also get people talking - I remember in England a national newspaper (I think it was the Guardian) ran a campaign promoting "Joy". The idea was to see if you could raise awareness of something that didn't exist, just a brand. It worked amazingly well, somebody even put up a "Joy" poster in our 6th form centre. By getting people saying "What's all this Linux Get Ready stuff about?" to each other, you could raise awareness much faster than through pure word of mouth.
I feel the feeling exact opposite is happening. Slashdot, as well as the other Linux sites are constantly bombarding us with news of Microsoft's dastardly deeds.
True, but there are a lot of them. And there's plenty of Linux news too. Software updates mainly, but also interesting and useful discussion on what can be made better.
The idea that Microsoft is paranoid and fearing Linux might be true, but is totally overblown. Microsoft fears any competition, the most likely competitor is Apple more than Linux.
Hardly. I don't see Microsoft claiming Apple is *the* threat to them. At the moment, they're getting their asses kicked in the server arena mainly, rather than the desktop, that's what worries them for now.
Oh, and for the record, Linux already has higher market share than MacOS X, which is probably why they want Apple to speed up deployment of it (no, really, this isn't a troll)
I think this is inevitable. Hotmail are starting to charge too. The days of free email are over guys.
I thought Apple could get away with it, as they just added the cost to the hardware but clearly not. Expect to see this coming to your free email service soon (unless like me, your email account is provided by a friend -thanks theo;)
Well, Oddpost manage to do it for 30 dollars a year. Now, that doesn't include web hosting or anything - but most mac.com users were in it for the email right?
Oddpost, for the record, is an insanely cool company. They provide paid for email - but, and this is the rub, they also provide a kickass DHTML front end to it. Unfortunately it's IE/Win only, so not much use to me (a tuxer) or to any of the Mac users. However, they also provide IMAP4 access with lots of space, so it isn't too bad.
Microsoft today demonstrated Visual Studio.NET, ASP.NET, a beta of the new database driven Longhorn and much more.
Doesn't a demonstration of such kickass tech (especially the database filing system stuff) realised today fro the consumer show just how many streets ahead Microsoft are?
This is stuff that should exist on the Mac, but doesn't. While Apple focused on gee-whiz features in an attempt to get more upgrades, Microsoft has retained their lead in producing leading edge tools and pushed forward computing - they can only produce better and better products.
PS: But is all seriousness, my reluctance to make my move is based on the apparent lack of Sequencing software and hardware support for my music equipment (MIDI interfaces, multitracking recorder cards, etc.). What *does* exist out there only seems to be able to recognize a (*cough* *cough*) Sound Blaster MIDI port. Any suggestions?
Well, it's OT, but try ALSA 0.9 (you can get it in suse 8.0) with Rosegarden (rosegarden.sf.net). I've read only good things about these programs.
True Twylite, but like so many business documents from big corps, 99% of them is fluff. Several pages are blank, some are devoted to a list of sponsors etc. Quite a lot of it is like this:
"Federated identity is the key to reducing this friction and realizing new business taxonomies and opportunities, coupled with new economies of scale".
Now to us lot, who are mainly I'd guess engineers, that sentance means nothing. It's just filling airspace, because it'll be read not just by developers but also their business oriented bosses who find stuff like this interesting and informative. Also - look at the prices! Do you think a company that spent $120,000 is going to be happy if all they get back for that work is a 10 page RFC?
Yes, but Macs have one big problem - they are proprietary hardware (and software, but the hardware is what is relevant).
Let's assume that the Norweigan government want to junk Windows, and have 1000 machines that they wish to junk it from. The average price of a Mac (taking the mean of all the different models) is about £1000. I don't know what that is in Kroner (?), but that comes to a cool million quid. For what? New hardware, that they don't need.
A million pounds! That's about 1.5 million US dollars I think. That's a lot of taxpayers cash.
And before somebody rants off about how it'd cost a million dollars to support Linux, I'd like to dispell this myth that somehow nobody needs to support or administer Macs. People say "they are so easy to configure, Linux is hard". But you don't want users reconfiguring network terminals anyway, so that isn't an issue. "Software installation is hard". Ditto. All the stuff that they need, ie writing office documents, browsing the net, checking email etc Linux does just fine, and more importantly, does it without the HUGE cost of rebuying Microsoft Office (I read $500 somewhere, which is also crazy). For organisations that already have computers, Macs are uneconomic, and no amount of guesswork based on TCO will change that. Period.
Nah, I'd use my new godlike powers to force MS to document the formats properly. There's nothing intrinisically wrong with the.doc format as far as I know, certainly forcing the use of ASCII or RTF (even xhtml) would be a step backwards in some respects. The problem isn't Microsoft technologies some of which are good, the problem is that people get locked in to them
Why do I think that? From poor language support to lack of DVD options, Linux just isn't ready for the desktop.
Sorry? Poor language support? Every third screenshot I see of Linux is in a language I don't even recognise. Some Linux apps have been translated into a huge number of languages. Also, remember that this is open source we're talking here - apart from the fact that many Norweigans talk fluent English, they can always translate the programs themselves. It's normally pretty trivial.
DVD options - hello, this is a government contract? They don't need DVD support, and if they did, well they could have it anyway. Getting DVDs on Linux is basically a 2 step process now: install Xine, install a DeCSS plugin. That's it.
Add to that the known problems it has on the server end and you have a recipe for disaster.
Please elaborate. I can't think of any off the top of my head, in fact I believe Samba performs almost as well as Windows NT if your thinking about Windows integration.
Ultimate gratitude: MS ought to be kissing Apple's ass for keeping the Feds off of them this long.
That's one way of looking at it. Another is that Apple should be kissing Microsofts ass for keeping them alive this long. If MS hadn't invested in Apple when it did, there would be no Apple today.
Localization and language support are going to be an issue here.
Not really. I don't know how good Windows Norweigan support is (pretty good I'd imagine) but KDE has been translated into over 40 languages iirc, and many other Linux apps also have Norweigan translations.
You would never be able to tell normally as GNU gettext hides it all from the user.... in fact I just checked, and I have almost 30 norweigan translations on my machine, and I haven't installed any special language packages or anything.
I know I'll get modded down for this, as it criticises Apple, but oh well.....
Just saw a commercial about how much more "intuative" OSX is than Windows. Apple's running these commercials all the time. They're definatly pushing it hard.
I haven't seen them on TV at all. I think these ads are US only, in fact that wouldn't surprise me - I've seen one or two at a friends house (yes, he really does download adverts). Basically they wouldn't be allowed in most of Europe, as some of them are incredibly misleading and the article is right - they could be seen as direct attacks on Microsoft. It's a lot harder to directly attack competitors on European TV, though not impossible (you're supposed to market your products based on their strengths, nothing else).
However, some of them really were surprising. Take the one with that guy going on about blue screens, and how you never see them on a Mac (well, duh). In fact, this is playing on peoples prejudices, by comparing Apple's latest generation technology with stuff that is now 4 years old from Microsoft. A properly set up XP or 2000 machine should rarely, if ever blue screen. I wonder if their execs would understand if it was phrased like this: How would Apple like it if MS ran adverts comparing Windows XP or 2K to MacOS 8/9? MacOS would be flattened of course, versions previous to OS X sucked.
To be honest, it's this sort of ultra aggresive marketing that switches me off (no pun intended) from Apple. These sorts of adverts, combined with the amount of software they're buying up and making Mac only, are a big no no in my books.
Yeah, checkinstall is neat, I love installwatch in particular. This solves the problem partially by allowing you to combine source and binary installations, but it doesn't solve all the other problems as well. Also of course, if there isn't an RPM for your distro, you still have to get it to build from the source which can be a hassle.
Definately a cool program, and useful for now until we sort this situation out once and for all. Kudos to the guys who wrote it.
The problem I see with all those package repositeries (such as Debian's, RedCarpet, Gentoo portage's, freshrpms, autopackage's, etc.) is that you must wait for somebody to do the work of the packaging for you if you want to install something.
Exactly, this is why the autopackage network would be different. Rather than having huge teams of packagers like Debian has, which will invariably miss stuff, it works in a way similar to DNS. Let me explain:
You install package "genst" - it generates simple source trees by the way, and I'm using it for development because it's simple. Genst has 2 dependancies, on libxml (developed by the gnome team) and on the dialog utility which has floated around in various versions for a long time and doesn't really have an official home site anymore.
In the autopackage, some dependancy checks are made to ensure you have the correct versions of libxml and dialog. If these tests fail - now what? In the Debian system, your computer would try and download the needed files from ftp.debian.org, a huge collection of packages, all hand maintained.
For autopackage however, what happens is that a resolution process begins. Each package has what's called a root name which looks like this: "@gnome.org/libxml/2.0" or "@advancedresearch.org/dialog/0.9". It leverages off DNS for keeping names unique by the way. Your computer now attempts to turn this root name into a URL from which the necessary package (which could be an RPM) can be downloaded. The difference is that that's all the autopackage network does: responsibility for building and maintaining the package is the software developers responsibility whenever possible. That's why I'm focussed on letting the production of autopackages as simple as possible, so the developers themselves can package their software with minimal effort. I think the attraction of being able to offer a binary download that'll work on all distributions will be enough to get started with, along with some gentle persuasion;)
Anyway, the route by which root names are turned into URLs is pretty flexible, for instance your distro could override it (similar to apt.sources) so that if you try and upgrade X, it'll get the package from the distro servers rather than the xfree servers. Hopefully we'll end up with a hybrid system, whereby most packages reside on the project servers, rather than a central database, and therefore the packages are always up to date.
I'd like to be able to install it correctly (ie, using my package manager) alone, possibly sharing the method used (spec file or equivalent) afterwards. Doing a RPM or a deb is actually quite easy for standard packages (the configure; make; make install kind of packages). But it could be even simpler. I'd put my efforts on that part of the packaging system.
Nice idea, but not always practical. For starters, most people don't want to compile software from the source. When it works it takes ages. It often doesn't work, and you must install large numbers of -devel packages to get the C headers etc. RPMs are also limited - there's no way of customising the install based on user interaction for instance.
Limiting the source of the packages a user can install on their system by using said repositeries, even if they're comprehensive and large, is a counterproductive step IMHO.
Exactly, that's why autopackage tests the system directly rather than having a big repository. You can get the files you need from anywhere, not just your package manager.
So say I copy package A from another machine. I then install package B, which requires something that package A has. Your script just sees that it exists and continues on with the install. Then I uninstall package A. Without a database to keep track of dependencies, how do you know what will break by doing an uninstall?
You don't. If you do copy stuff from another machine, then it wouldn't be in a database anyway, so you still wouldn't get any warnings if you deleted it if you were using RPM.
The approach autopackage takes here is that having a database of everything on your system is a bad idea, as that db will invariably get out of synch. The system is the best database. So let's say we have the situation you described. You somehow remove something that another program needs, and you do it manually so there are no warnings. Suddenly, a program will break. In this case, you run the apkg-verify command, which will look at the dependancies of this package (let's say you install package "genst" that needs libxml, and you remove libxml).
The verify command now loads up the package skeleton for libxml as it knows this is a dependancy of genst (the package skeletons describe uninstall info/file lists/dependancy tests). It runs the test in the libxml skeleton, and sees that it fails. It now offers you the option of redownloading and installing the package.
This isn't the ideal approach, as the user would much rather have been warned beforehand. However, other than by overriding the "rm" command (which could be done, but I doubt it'd be popular) there is no way of stopping the user mangling their system in such a way. Being able to copy files from another machine or install from the source will always have this problem, as it's not registered in any database.
If you can think of a better way of doing this, then please tell me. I've been thinking about it for most of the afternoon, and for the rare cases in which you delete things like this (most users would use the uninstall commands and not copy files from other computers) the verify mechanism would work, and not require too much implementation effort.
Macs have shared libraries as well. The frameworks contain them, and abstract them for ease-of-upgrading (frameworks can contain multiple versions of libraries for backwards compatibility).
You can also build non-framework dynamic libraries and put them in/usr/local/lib or/usr/lib just like you can on any other unix.
I never said Macs didn't have shared libraries. What I said was they aren't used to nearly the same extent as on other platforms. Also, frameworks are largely only addable by Apple. How do you ensure your program always has a particular framework? There is no way, except by using an installer stub like InstallShield/Wise. It's easier to simply say "requires 10.2" or whatever, which isn't really code sharing.
Does that mean that OS X applications don't use any shared libraries? Sounds like 1990.
For the record, I'm anti-mac - we don't need another repeat of the Windows debacle. However, this is a technical issue, so I'll try and be unbiased. Here is what I've learned from asking the same question:
Mac's don't have shared libraries as such, the closest there is (in os x at least) is Frameworks. Frameworks are collections of features, I'd guess they're made up of shared libraries but I'm not sure. Frameworks can be installed by dragging them into the frameworks folder (in the library). However, I've never heard of anybody actually doing that, basically Apple are the only ones who put new frameworks on the system.
Many Mac apps are atomic, ie they are stored in a folder with a special attribute. To "install" them, you just drag the appfolder to the Applications folder. This is great from the users point of view, it keeps things simple. I looked into it for my autopackage project (see another post i made for details). However, it turns out this is a technically extremely poor way of doing things. It means there is virtually no code reuse on the Mac, as there is no dependancy tracking engine. It means that apps distributed as appfolders also do not have any install process AT ALL, so they cannot ask for EULA agreements, check your system for stuff it needs, alter its configuration and so on. The appfolders system is good enough only for very simple apps.
So Apple ship an "Installer" program also. This is used by some more complex apps, but I'm not sure what it's capabilities are. Usually, the result of the install program is simply a new appfolder, except in cases like XDarwin which add files outside the Mac namespace. Sometimes if neither of these approaches work well enough, Mac programs ship with InstallShield style installer stubs, with the problems this entails (no headless network install for instance).
So we can see that the Mac has the most inferior software management system of all the platforms (even linux, which at least tries) from a technical perspective. From the users point of view, it is ideal. Typical Apple design here - I'm not going to comment on whether this is a good or bad thing.
Conclusion: the Mac has the simplest and most direct method of managing software you can get, but at a big sacrifice, as there is no code reuse (there is no equivalent to COM/CORBA as far as I can see either) and apps are incredibly limited as to what they can do during installation. Because of this, some apps work around the appfolder system by using installer stubs, negating the whole point of the system (simplicity, consistancy ) in the first place.
Interesting you should mention this. I'm working on something called autopackage, which does exactly this.
The situation MUST become the same for Linux. There must come to be some "blessed" slick GUI installer that can also run "headless" from a command line.
Check. Autopackage is (currently) written largely in bash, but has a clean split between the backend and front end for exactly this reason. The BE and FE are actually two separate processes which communicate via a simple protocol based on unix named pipes. Right now, there is only a terminal front end, but when it's released as an OSS project (soon) I'll be looking for people to help me write KDE and GTK based installers.
It should implement a state transition engine and run from a state machine which goes from an initial state "not-installed", through paths for the distros, dependencies to a terminal state of "software registered."
Check. Autopackage deals with dependancies differently to other package managers, as it doesn't have a huge central database of everything that's on the system (it keeps enough information around to uninstall packages though obviously). Instead, it probes the system for everything the package needs - for instance it currently checks for libraries using ldconfig. If it's in the Linux Linker cache, the check is passed. This means you can install stuff from the source, or even just copy files from a friends computer without worrying about your package manager database getting out of synch.
To make the situation complete, it must detect the distro (and therefore the install paths, dependencies and destination directories,) the GUI in use, if any, and be able to completely install AND UNINSTALL by walking backwards through the installer log undoing what was done and cleaning up all debris.
Check. An autopackage is actually a program that you run (don't worry, the overhead is tiny). If you have autopackage installed, the scripts are processed and the user is greeted with a friendly GUI installer (if run from X) or if run from the command line you get the tty front end. If you don't have autopackage installed, it'll offer to automatically fetch everything the user needs from the net including a distro profile.
The profile contains all the information needed to slot files into the correct places, and perform the correct actions for adding menu items etc. If there is no profile for the users distro, I intend to have a way of letting the user easily create one (though this will probably not be an operation that can be performed by a total newbie) and then optionally upload the resultant profile for checking and inclusion. This deals with cases where people have built their own systems, or have customised them a lot.
The installer "experience" is standard for the user because everybody is using the same packages or near clones of these packages to install any and every ol' thing.
That isn't going to happen soon, which is why autopackage will integrate (at least to some extent) with RPM and perhaps Debian too. However, I intend to eventually create something similar to the apt repositories, except decentralised so it acts more like DNS rather than having huge libraries of packages that must be manually updated. I hope, dream, that one day Linux software authors will provide an autopackage as standard as well as the source tarball (they are pretty easy to make), which will plug into the autopackage network and allow you to install and update them using an apt type system.
Umm, what else? Oh yes, it's pretty flexible about asking the user stuff. The user can be asked questions during the install like which prefix to use (defaults chosen from the profile), or for commecial software they can be asked for license keys, to read EULAs and so on (commercial software is coming to linux like it or not, so i thought I might as well add these features). However, I had a bad experience once where I spent a whole week installed IE5 on each and every machine in a company by hand, so rest assured, being able to do automatic remote installs is high on my list of priorities.
I still have some basic foundation and design work to do on it, but I'm hoping it'll be out on freshmeat and ready for hacking by the end of the summer. If you're interested, then please email me. This should go a long way to solving the software management mess that Linux has somehow got itself into.
Slashdot Mirror
Hardly. Most distros and projects have experimented with the GCC 3 series, but it's not yet good enough. For instance, although KDE actually compiles with it now, it takes twice as long, and produces slower code as well. That's why they're not using it.
Maybe these bugs don't exist in the Objective-C parts of it, I don't know. But using the latest GCC when it's not yet actually better than the previous is hardly "keeping on top of UNIX technology"
I don't have time right now, I'm too busy working on autopackage, but is anybody else interested?
OK, so some people would say "for crying out loud, it's just an operating system", but for others they might be interested in the story behind it. Think about it - the history of Linux is a great story, and more to the point, it's a human interest story. Of course I don't think the revolution idea would be good at all for actually selling Linux, but for raising awareness I think it might do the trick. You can always tailor the marketing for specific groups of people (server admins, home desktop users etc) later.
I don't think this is right. Windows is hated not because it's dominant per se, in fact many people like it's dominance as it means easier to learn computers - what people hate is the feeling that they have no choice, that they MUST put up with the general poorness of Windows/Office. That wouldn't apply with Linux. Look how many distros there are already, and how different they are.
What goals does the Linux community have, other than supplanting Windows?
Well, my goal is to ensure the dominance of open platforms. Too much damage is done by closed platforms, and as I am going to spend most of the rest of my life in the computer industry, I want to ensure we have a stable foundation to go from.
I don't think advertising would be bad per se, as long as it was done right. I think most "computer people" now know at least what Linux is, if not much about it. So what's needed (but not yet, linux isn't ready for home desktops yet) is advertising that plants the seeds of curiousity in peoples minds - that gets them asking "What is Linux?". They can then ask their local geek, who will (hopefully) expound upon them it's greatness (the excuse being, they did ask ;)
You say you have a marketing background. So what do you think of this? Let's say we have a hypothetical campaign. Like most stuff to do with linux, it doesn't have much money, let's say we rule out TV advertising. So we need to get far more awareness for each pound, dollar, euro we spend than other campaigns.
Linux came from the streets. It's not like other products. Therefore, we can get away with a different sort of advertising. We can play upon the "revolutionary" aspects of it. Let's say, for a month or two, in the major cities of the world some billboard space is bought up, and filled with simple posters that have a faded picture of tux, with slogans such as "Get Ready", "Join the revolution" or "Power to the People" overlayed. Perhaps one or two have the word "Linux" underneath, so people know what to ask about, what to call it.
IBM had a neat idea - people associate "revolution from the streets" with graffiti. It doesn't have to be illegal, if you as a landlord had a spare wall lying around, wouldn't you jump at a chance to earn a bit of money from it by letting these friendly guys spray paint some words on the side? As long as they clean up afterwards.....
The aim would be to raise lots of awareness rather than promote the product which is hard to get across in adverts anyway (distro? what's a distro?). That vague awareness could then be turned into enthusiasm by word of mouth from geeks and other happy users. It'd also get people talking - I remember in England a national newspaper (I think it was the Guardian) ran a campaign promoting "Joy". The idea was to see if you could raise awareness of something that didn't exist, just a brand. It worked amazingly well, somebody even put up a "Joy" poster in our 6th form centre. By getting people saying "What's all this Linux Get Ready stuff about?" to each other, you could raise awareness much faster than through pure word of mouth.
Good idea? Bad idea?
True, but there are a lot of them. And there's plenty of Linux news too. Software updates mainly, but also interesting and useful discussion on what can be made better.
The idea that Microsoft is paranoid and fearing Linux might be true, but is totally overblown. Microsoft fears any competition, the most likely competitor is Apple more than Linux.
Hardly. I don't see Microsoft claiming Apple is *the* threat to them. At the moment, they're getting their asses kicked in the server arena mainly, rather than the desktop, that's what worries them for now.
Oh, and for the record, Linux already has higher market share than MacOS X, which is probably why they want Apple to speed up deployment of it (no, really, this isn't a troll)
I thought Apple could get away with it, as they just added the cost to the hardware but clearly not. Expect to see this coming to your free email service soon (unless like me, your email account is provided by a friend -thanks theo ;)
Oddpost, for the record, is an insanely cool company. They provide paid for email - but, and this is the rub, they also provide a kickass DHTML front end to it. Unfortunately it's IE/Win only, so not much use to me (a tuxer) or to any of the Mac users. However, they also provide IMAP4 access with lots of space, so it isn't too bad.
Doesn't a demonstration of such kickass tech (especially the database filing system stuff) realised today fro the consumer show just how many streets ahead Microsoft are?
This is stuff that should exist on the Mac, but doesn't. While Apple focused on gee-whiz features in an attempt to get more upgrades, Microsoft has retained their lead in producing leading edge tools and pushed forward computing - they can only produce better and better products.
Yay.
Well, it's OT, but try ALSA 0.9 (you can get it in suse 8.0) with Rosegarden (rosegarden.sf.net). I've read only good things about these programs.
Now to us lot, who are mainly I'd guess engineers, that sentance means nothing. It's just filling airspace, because it'll be read not just by developers but also their business oriented bosses who find stuff like this interesting and informative. Also - look at the prices! Do you think a company that spent $120,000 is going to be happy if all they get back for that work is a 10 page RFC?
Let's assume that the Norweigan government want to junk Windows, and have 1000 machines that they wish to junk it from. The average price of a Mac (taking the mean of all the different models) is about £1000. I don't know what that is in Kroner (?), but that comes to a cool million quid. For what? New hardware, that they don't need.
A million pounds! That's about 1.5 million US dollars I think. That's a lot of taxpayers cash.
And before somebody rants off about how it'd cost a million dollars to support Linux, I'd like to dispell this myth that somehow nobody needs to support or administer Macs. People say "they are so easy to configure, Linux is hard". But you don't want users reconfiguring network terminals anyway, so that isn't an issue. "Software installation is hard". Ditto. All the stuff that they need, ie writing office documents, browsing the net, checking email etc Linux does just fine, and more importantly, does it without the HUGE cost of rebuying Microsoft Office (I read $500 somewhere, which is also crazy). For organisations that already have computers, Macs are uneconomic, and no amount of guesswork based on TCO will change that. Period.
Nah, I'd use my new godlike powers to force MS to document the formats properly. There's nothing intrinisically wrong with the .doc format as far as I know, certainly forcing the use of ASCII or RTF (even xhtml) would be a step backwards in some respects. The problem isn't Microsoft technologies some of which are good, the problem is that people get locked in to them
Sorry? Poor language support? Every third screenshot I see of Linux is in a language I don't even recognise. Some Linux apps have been translated into a huge number of languages. Also, remember that this is open source we're talking here - apart from the fact that many Norweigans talk fluent English, they can always translate the programs themselves. It's normally pretty trivial.
DVD options - hello, this is a government contract? They don't need DVD support, and if they did, well they could have it anyway. Getting DVDs on Linux is basically a 2 step process now: install Xine, install a DeCSS plugin. That's it.
Add to that the known problems it has on the server end and you have a recipe for disaster.
Please elaborate. I can't think of any off the top of my head, in fact I believe Samba performs almost as well as Windows NT if your thinking about Windows integration.
That's one way of looking at it. Another is that Apple should be kissing Microsofts ass for keeping them alive this long. If MS hadn't invested in Apple when it did, there would be no Apple today.
Not really. I don't know how good Windows Norweigan support is (pretty good I'd imagine) but KDE has been translated into over 40 languages iirc, and many other Linux apps also have Norweigan translations.
You would never be able to tell normally as GNU gettext hides it all from the user.... in fact I just checked, and I have almost 30 norweigan translations on my machine, and I haven't installed any special language packages or anything.
Hmmm, interesting viewpoint. I hadn't thought of it like that - thanks! Maybe it isn't such a bad idea after all......
Just saw a commercial about how much more "intuative" OSX is than Windows. Apple's running these commercials all the time. They're definatly pushing it hard.
I haven't seen them on TV at all. I think these ads are US only, in fact that wouldn't surprise me - I've seen one or two at a friends house (yes, he really does download adverts). Basically they wouldn't be allowed in most of Europe, as some of them are incredibly misleading and the article is right - they could be seen as direct attacks on Microsoft. It's a lot harder to directly attack competitors on European TV, though not impossible (you're supposed to market your products based on their strengths, nothing else).
However, some of them really were surprising. Take the one with that guy going on about blue screens, and how you never see them on a Mac (well, duh). In fact, this is playing on peoples prejudices, by comparing Apple's latest generation technology with stuff that is now 4 years old from Microsoft. A properly set up XP or 2000 machine should rarely, if ever blue screen. I wonder if their execs would understand if it was phrased like this: How would Apple like it if MS ran adverts comparing Windows XP or 2K to MacOS 8/9? MacOS would be flattened of course, versions previous to OS X sucked.
To be honest, it's this sort of ultra aggresive marketing that switches me off (no pun intended) from Apple. These sorts of adverts, combined with the amount of software they're buying up and making Mac only, are a big no no in my books.
Well, just my 2 cents.
Join Arianne
Know Arianne
RoadMap
Who is who
Latest Code
Oooh err, we get to "know" Arianne as well? Anybody else find those biblical connotations amusing?
Definately a cool program, and useful for now until we sort this situation out once and for all. Kudos to the guys who wrote it.
Exactly, this is why the autopackage network would be different. Rather than having huge teams of packagers like Debian has, which will invariably miss stuff, it works in a way similar to DNS. Let me explain:
You install package "genst" - it generates simple source trees by the way, and I'm using it for development because it's simple. Genst has 2 dependancies, on libxml (developed by the gnome team) and on the dialog utility which has floated around in various versions for a long time and doesn't really have an official home site anymore.
In the autopackage, some dependancy checks are made to ensure you have the correct versions of libxml and dialog. If these tests fail - now what? In the Debian system, your computer would try and download the needed files from ftp.debian.org, a huge collection of packages, all hand maintained.
For autopackage however, what happens is that a resolution process begins. Each package has what's called a root name which looks like this: "@gnome.org/libxml/2.0" or "@advancedresearch.org/dialog/0.9". It leverages off DNS for keeping names unique by the way. Your computer now attempts to turn this root name into a URL from which the necessary package (which could be an RPM) can be downloaded. The difference is that that's all the autopackage network does: responsibility for building and maintaining the package is the software developers responsibility whenever possible. That's why I'm focussed on letting the production of autopackages as simple as possible, so the developers themselves can package their software with minimal effort. I think the attraction of being able to offer a binary download that'll work on all distributions will be enough to get started with, along with some gentle persuasion ;)
Anyway, the route by which root names are turned into URLs is pretty flexible, for instance your distro could override it (similar to apt.sources) so that if you try and upgrade X, it'll get the package from the distro servers rather than the xfree servers. Hopefully we'll end up with a hybrid system, whereby most packages reside on the project servers, rather than a central database, and therefore the packages are always up to date.
I'd like to be able to install it correctly (ie, using my package manager) alone, possibly sharing the method used (spec file or equivalent) afterwards. Doing a RPM or a deb is actually quite easy for standard packages (the configure; make; make install kind of packages). But it could be even simpler. I'd put my efforts on that part of the packaging system.
Nice idea, but not always practical. For starters, most people don't want to compile software from the source. When it works it takes ages. It often doesn't work, and you must install large numbers of -devel packages to get the C headers etc. RPMs are also limited - there's no way of customising the install based on user interaction for instance.
Limiting the source of the packages a user can install on their system by using said repositeries, even if they're comprehensive and large, is a counterproductive step IMHO.
Exactly, that's why autopackage tests the system directly rather than having a big repository. You can get the files you need from anywhere, not just your package manager.
You don't. If you do copy stuff from another machine, then it wouldn't be in a database anyway, so you still wouldn't get any warnings if you deleted it if you were using RPM.
The approach autopackage takes here is that having a database of everything on your system is a bad idea, as that db will invariably get out of synch. The system is the best database. So let's say we have the situation you described. You somehow remove something that another program needs, and you do it manually so there are no warnings. Suddenly, a program will break. In this case, you run the apkg-verify command, which will look at the dependancies of this package (let's say you install package "genst" that needs libxml, and you remove libxml).
The verify command now loads up the package skeleton for libxml as it knows this is a dependancy of genst (the package skeletons describe uninstall info/file lists/dependancy tests). It runs the test in the libxml skeleton, and sees that it fails. It now offers you the option of redownloading and installing the package.
This isn't the ideal approach, as the user would much rather have been warned beforehand. However, other than by overriding the "rm" command (which could be done, but I doubt it'd be popular) there is no way of stopping the user mangling their system in such a way. Being able to copy files from another machine or install from the source will always have this problem, as it's not registered in any database.
If you can think of a better way of doing this, then please tell me. I've been thinking about it for most of the afternoon, and for the rare cases in which you delete things like this (most users would use the uninstall commands and not copy files from other computers) the verify mechanism would work, and not require too much implementation effort.
You can also build non-framework dynamic libraries and put them in /usr/local/lib or /usr/lib just like you can on any other unix.
I never said Macs didn't have shared libraries. What I said was they aren't used to nearly the same extent as on other platforms. Also, frameworks are largely only addable by Apple. How do you ensure your program always has a particular framework? There is no way, except by using an installer stub like InstallShield/Wise. It's easier to simply say "requires 10.2" or whatever, which isn't really code sharing.
For the record, I'm anti-mac - we don't need another repeat of the Windows debacle. However, this is a technical issue, so I'll try and be unbiased. Here is what I've learned from asking the same question:
Mac's don't have shared libraries as such, the closest there is (in os x at least) is Frameworks. Frameworks are collections of features, I'd guess they're made up of shared libraries but I'm not sure. Frameworks can be installed by dragging them into the frameworks folder (in the library). However, I've never heard of anybody actually doing that, basically Apple are the only ones who put new frameworks on the system.
Many Mac apps are atomic, ie they are stored in a folder with a special attribute. To "install" them, you just drag the appfolder to the Applications folder. This is great from the users point of view, it keeps things simple. I looked into it for my autopackage project (see another post i made for details). However, it turns out this is a technically extremely poor way of doing things. It means there is virtually no code reuse on the Mac, as there is no dependancy tracking engine. It means that apps distributed as appfolders also do not have any install process AT ALL, so they cannot ask for EULA agreements, check your system for stuff it needs, alter its configuration and so on. The appfolders system is good enough only for very simple apps.
So Apple ship an "Installer" program also. This is used by some more complex apps, but I'm not sure what it's capabilities are. Usually, the result of the install program is simply a new appfolder, except in cases like XDarwin which add files outside the Mac namespace. Sometimes if neither of these approaches work well enough, Mac programs ship with InstallShield style installer stubs, with the problems this entails (no headless network install for instance).
So we can see that the Mac has the most inferior software management system of all the platforms (even linux, which at least tries) from a technical perspective. From the users point of view, it is ideal. Typical Apple design here - I'm not going to comment on whether this is a good or bad thing.
Conclusion: the Mac has the simplest and most direct method of managing software you can get, but at a big sacrifice, as there is no code reuse (there is no equivalent to COM/CORBA as far as I can see either) and apps are incredibly limited as to what they can do during installation. Because of this, some apps work around the appfolder system by using installer stubs, negating the whole point of the system (simplicity, consistancy ) in the first place.
The situation MUST become the same for Linux. There must come to be some "blessed" slick GUI installer that can also run "headless" from a command line.
Check. Autopackage is (currently) written largely in bash, but has a clean split between the backend and front end for exactly this reason. The BE and FE are actually two separate processes which communicate via a simple protocol based on unix named pipes. Right now, there is only a terminal front end, but when it's released as an OSS project (soon) I'll be looking for people to help me write KDE and GTK based installers.
It should implement a state transition engine and run from a state machine which goes from an initial state "not-installed", through paths for the distros, dependencies to a terminal state of "software registered."
Check. Autopackage deals with dependancies differently to other package managers, as it doesn't have a huge central database of everything that's on the system (it keeps enough information around to uninstall packages though obviously). Instead, it probes the system for everything the package needs - for instance it currently checks for libraries using ldconfig. If it's in the Linux Linker cache, the check is passed. This means you can install stuff from the source, or even just copy files from a friends computer without worrying about your package manager database getting out of synch.
To make the situation complete, it must detect the distro (and therefore the install paths, dependencies and destination directories,) the GUI in use, if any, and be able to completely install AND UNINSTALL by walking backwards through the installer log undoing what was done and cleaning up all debris.
Check. An autopackage is actually a program that you run (don't worry, the overhead is tiny). If you have autopackage installed, the scripts are processed and the user is greeted with a friendly GUI installer (if run from X) or if run from the command line you get the tty front end. If you don't have autopackage installed, it'll offer to automatically fetch everything the user needs from the net including a distro profile.
The profile contains all the information needed to slot files into the correct places, and perform the correct actions for adding menu items etc. If there is no profile for the users distro, I intend to have a way of letting the user easily create one (though this will probably not be an operation that can be performed by a total newbie) and then optionally upload the resultant profile for checking and inclusion. This deals with cases where people have built their own systems, or have customised them a lot.
The installer "experience" is standard for the user because everybody is using the same packages or near clones of these packages to install any and every ol' thing.
That isn't going to happen soon, which is why autopackage will integrate (at least to some extent) with RPM and perhaps Debian too. However, I intend to eventually create something similar to the apt repositories, except decentralised so it acts more like DNS rather than having huge libraries of packages that must be manually updated. I hope, dream, that one day Linux software authors will provide an autopackage as standard as well as the source tarball (they are pretty easy to make), which will plug into the autopackage network and allow you to install and update them using an apt type system.
Umm, what else? Oh yes, it's pretty flexible about asking the user stuff. The user can be asked questions during the install like which prefix to use (defaults chosen from the profile), or for commecial software they can be asked for license keys, to read EULAs and so on (commercial software is coming to linux like it or not, so i thought I might as well add these features). However, I had a bad experience once where I spent a whole week installed IE5 on each and every machine in a company by hand, so rest assured, being able to do automatic remote installs is high on my list of priorities.
I still have some basic foundation and design work to do on it, but I'm hoping it'll be out on freshmeat and ready for hacking by the end of the summer. If you're interested, then please email me. This should go a long way to solving the software management mess that Linux has somehow got itself into.