The head of Russia's Federal Bodyguard Service has warned of a plot by terrorist Osama bin Laden to assassinate George W. Bush at the summit and the U.S. President may be staying at U.S. Camp Darby military base in Livorno or offshore on the American aircraft carrier, USS Enterprise to avoid any terrorist risk.
If Blair, Chirac, Putin, etc. were staying on a cruise ship but suddenly Bush had to stay at a military installation instead of joining them to avoid the possibility of Bin Laden crashing airplanes into the conference (hence the anti-aircraft missiles at the airport)... shouldn't that make an impression on Dear Leader? Someone in the administration took the threat seriously at Genoa in July: That is a fact. Had I been shifted to military accommodations, I would have known there was a threat - anyone would.
Then seeing a briefing titled "Bin Ladin Deteremined to Strike in US" a few weeks later elicited no response from Bush, even knowing that Bin Laden had struck the US at least twice on the past (USS Cole and the basement of the WTC).
To me, he looks like a coward who went on a very long vacation away from Washington, DC in order to avoid getting whacked.
I agree the "Linux" misnomer is quite awful. As platforms go, its really more of a mass hallucination.
OTOH for basic functionality, the LSB seems as meaningful as "BSD". In a couple of months, we will also have the LSB Desktop spec (to include APIs like Gtk+ and Qt allowing developers to target desktop users, but without the KDE/Gnome desktop layer itself).
The Webmail extension for Thunderbird can access Yahoo Mail and also updates regularly. However its so easy to update extensions that I don't mind.
If you want Yahoo-->IMAP, just setup an IMAP server (or an account with a provider like Fastmail) then setup a TB rule to move the Webmail onto your IMAP server.
They're encouraging developers to think, "Ooh shiny! I want!"
How this is any more special then authenticating over TLS/POP3 is anyone's guess at this point. But I'll speculate that this is a way to entice developers to use Yahoo as a defacto authentication service as MS Passport aimed to be.
Personally, I think users have moved on. Our browsers remember our passwords, and its not hard to synchronize password DBs between browsers if you use more than one.
Think of this Yahoo authentication "openness" as a counterweight to the Google browser-sync tool. I prefer the Google idea, since Google only ever gets my browser data in encrypted form whereas Yahoo-as-authentication-server means that a breakin or abuse of the password DB == users getting screwed.
I want to know what makes Firefox a part of the OS in Debian's eyes, such that they are imposing these policies. What is this Debian product that lists Firefox as an integral feature?
If the answer is that every application in the Debian repositories gets reworked at-will by Debian, with no thought to misrepresenting identities, then what they're offering is no so much an OS as Katamari Damaci.:-) Or the Giant Ameboa From Outerspace.
The FOSS community needs to start discussing which classes of software needs weak identity to aid innovation, and which need strong identity for the users' sake. We also need to start drawing a visible line between the OS and auxiliary applications, because most user-facing applications need different policies than OS components.
The confusion is similar to other Linux-based distros, only manifesting more strongly in this case:
What is the OS and what are the "Extra apps"?
Does this mean Firefox is part and parcel of the OS, and if so then why is the whole domain of GUI stuff treated as extras? If not, then why the urgent need to impose their tweaks on those programs?
I keep getting the impression they don't want to have a clear policy on desktop use, reworking applications, trademarks, etc, so they just switch between different attitudes as each situation suits them. In the case of DCCA distro using "Debian" in their name, Debian enforced their trademark against the former. Huh?
Mozilla foundation enforces the trademark on Firefox & Thunderbird. They come from a corporate background (what was Netscape) and have considerable user-focus. Part of the focus means the exact handiwork they produce and support is clearly identifiable by the end-user.
StarDivision -> OpenOffice.org reflects a similar tradition.
OSDL seems much looser with "Linux". Vendors are allowed to say "Mambo Linux", as if they took the kernel, painted it a different color, added leather seats, and offered a re-worked kernel for direct use by the end-user. Meanwhile anyone who can recompile a kernel encourages this identity-abuse. But most of what the user is getting is NOT Linux... It's the GNU toolchain plus a massive amount of higher-level stuff that could theoretically be standardized into consistent a PC platform. Can the end-user clearly identify the "Linux" product when they want to try a new OS? Of course not... Nor can they "use Linux" directly, so it has little meaning to most people. "Linux" is a complete misnomer in this context, like telling shoppers to go into a car dealership and say "shifter" when inquiring about complete automobiles. OSDL/Linux comes from a decidedly informal coding or 'hacking' tradition, and still accommodates confusion about product identities.
So, some projects insist of trademark integrity (much) more than others. Frankly, I do not think OSDL should allow distros to refer to their automobile as a "shifter". In many cases even GNU/Linux is inaccurate, like saying "shifter+transmission", so Stallman et al aren't so clever or correct on this point.
The FOSS developer community does make design committments to end-users, when it comes to certain products like "Firefox" or "Truecrypt"... but those serving in the "Linux" namespace avoid such committments like the plague; they are there to impress and commit to their peers for the most part.
I'll close with this: "Linux" advocacy is usually an excercise in misleading users by implying there is some committment to a platform product at a level they can use and identify (though the avg user cannot use or identify a mere kernel). Hackers and techies think they are doing something that will be meaningful/recognizable to the end-user over the long term, when this is rarely the case. Firefox advocacy doesn't have this problem; If it did, Mozilla would only write Gecko, and the browsers based on it would be called "Gecko distros", having considerably different UIs, collectively claim less than 2% marketshare, and extension-writers couldn't reliably anticipate which API functions would be included.
"The British public does not want parliament screwing up the only broadcaster left who actually cares about their viewers, instead of their advertisers."
That is not to say they won't ever try to put one over on the British public.
Here in the USA, we have PBS which is beholden to the federally-funded CPB and is chock-full of sponsorship announcements/ads. The result is a particularly pallid, toothless news bureau. We occassionally see informative and critical programming in the form of NOW or Frontline, but it is not "news" and always comes months too late for people to do much of anything preventative. NPR (radio) is structured the same, although their news is quite popular mainly because it is peppered with novel aesthetics and many affiliates air the BBC World Service (to make up for all the NPR mistakes and omissions) immediately afterward.
IOW we have here a perfect model for a neoliberal "modernised" public broadcaster that is right up Blair/Brown's alley. Do not be surprised if you discover this is already the government policy.
Nano is very tiny, and could be added to the LSB with absolutely no trouble. Then one could say that anytime you hop onto a Linux system, you can choose nano if vi seems too arcane. From there, realizing that OS X also includes nano, it is not a stretch to say that nano would be emerging as a *nix standard. It is already used in most OS X examples as a common-sense way to do quick edits in the CLI.
The problem with vi is that to many people it is outright repulsive. When told to use it, I infer an underlying attitude of "We don't care about making you deal with unnecessarily arcane tools and formats". Still, I'm not saying it should be abandoned or removed... its just not a program that ought to be forced onto anyone at the 'Webhosting 101' or 'Junior Linux Admin' stages.
Sed and awk are fine the way they are, but people are not going to be expected to learn them just so they can perform rare, emergency system maintenance. With vi, its a different story.
That is how I see it anyway. If it were up to me, I would replace 80% of/etc stuff with XML files, making sure that a good text-mode XML editor with tree/node view was included. Too many subsystems on Linux integrate poorly because their config/control options are based on their/etc file, a custom format with vague rules and/or poor documentation. The first nonsense file format to be slayed would be xorg.conf. But that's just daydreaming.:-)
Your idea about relocating libraries for certain app dependencies reminds me of Apple appdirs: The non-standard version of the library stays in the appdir, and appropriately the vendor that supplied it with the app is responsible for how well it functions. I think that should be standard procedure when developing any app on any OS: If you insist on holding back to an older version than the OS specifies, then (if licensing allows) it is your job to include it with the app and have the app load it from its own folder. Making the rest of the system deal with your decision is just wrong, but unfortunately that's how its done on "Linux".
The HCL idea has been burning in my mind for over a year. If I could figure out a way to attract a real following (and some hardware expertise) to it, I'd set up a project website. Probably the first thing to do would be to compile information from the various fragmented hardware lists; these would be some starting points:
I'm with you. Having seen the difference between BBC content and the crap available here I think the results are in: state-funded broadcasting works better and costs less.
The BBC isn't state-funded. It's a public corporation funded by a flat amount that each viewer pays in the form of a license fee.
Since an organization's revenue stream will ultimately determine its biases, the BBC is funded independantly of the tax system. Charging a license fee in a "one-viewer-one-vote" fashion avoids conflicts of interest in covering both the private sector and state affairs. This helps dispell greed and political interference in how it goes about its job.
If the BBC received significant funds from tax revenue, then it would be a state-controlled broadcaster.
If they scaled the fee according to an individual's means, then their bias would slant toward serving the interests of the wealthy (which is what many anti-licensing activists very badly want).
A flat fee may not be a good model for many services. But for an organization that is supposed to serve the entire public without bias, to reflec that society which it serves, and to serve as a watchdog, IMO you cannot do better.
By just being in the wider broadcasting market, they change it for the better.
Yet even FOX News is typical of the coverage on Iran. They repeat deliberate mis-interpretations of what Iranian leaders say, and the scare over "wipe Israel off the map" is no different than the one about Iran legislating a dresscode for Jews. In the former case, we had the Iranian president saying that the Zionist regime must disappear from the page of time. Since Zionism can objectively be considered similar to Apartheid in crucial respects (not the least of which are its results).
I won't condone Iran's (or Israel's) theocracy, regardless of the particular style. Their involvement with Hizballah is questionable. But they are not a bunch of complete extremists. Iran is a country where women can get an education, show their faces, drive cars, and have access to birth control (compare that to our fascist allies, Saudi Arabia and Pakistan). Iran has a limited, nascent form of democracy and a great deal of technical sophistication.
They are independant of the West and that fact lands them squarely on the "must demonize" list. Iran is targeted for dehumanization all the more for its relative modernity, which gains them moral and cultural influence that makes it difficult for the West to propagandize the Middle East.
For our "civilized" western media, railing against a Zionist regime is eagerly mis-interpreted as a genocidal rant against Jews and an entire country. AND they do this at a time when the US is floating the idea of a "preventative" war and nuclear attack on Iran. Meanwhile, in the middle of all this self-righteous hyperventilating, our leaders get carte blanche to lie and spill vast amounts of blood elsewhere.
RMS is certainly correct when he says that free software would not put you in such a corner.
OTOH, you were really asking for it by expecting a whole-number upgrade to remain compatible with 3rd-party stuff. Even novices are supposed to understand that major whole-number upgrades are mostly likely to break compatability with previous versions as well as 'accessory' products and such.
Whenever I scratch a lotto ticket, it's "supposed" to be a winner. Modern Americans are nothing more than smug, fat, indolent and apathetic consumers, who serve no purpose other than to feed cash into the system.
You forgot the petrodollars that keep the whole thing energized. The more fossil fuel we consume, the more dollars we get to print and send to foreign countries in return for stuff. It wouldn't be so dishonest if all the fuel were all ours to begin with. The more we chase that cashflow, the greater the imperative for the US government to acquire oil&gas flows for its chartered energy interests. The real costs in efficiency, human life and environment tend to be ignored in the whole destructive cycle.
Least of all, don't do anything that would dry-up the ocean of desperation that corporations rely on for cheap labor. Empowering women with family planning and birth control options is incompatible with the "culture of life".
The things I don't agree with are the Core Desktop thing and apps not using system wide libraries. To me the idea of merging everything and filtering it down into one unit seems like a daunting task.
Some misunderstanding here I think: When I say 'core desktop' I mean core APIs that ISVs would use to target a broad desktop audience. For example X11, gtk+, qt, dbus, etc. I am not referring to an actual Gnome or KDE desktop.
I dislike man pages on Linux because 1) they sometimes say 'use info instead', and 2) they almost always omit examples. BSD is much nicer for 'man' and its one of the reasons I have grown to like OS X so much in the past 18 months since I bought a Mac.
As far as different applications bundling the libraries in with them, I have a feeling there might be some legal issues with that,
Indeed, independant commercial developers wouldn't be able to statically link GPL stuff for starters. All the more important that devs have assurance certain libraries will already exist in the system (even better if their program only has to check which LSB level the system is at).
A 12GB root seems very large to me. I notice my root tends to expand greatly when I've got a lot going in/usr/src. That would seem to indicate over-reliance on source code as mere distribution vehicle (as opposed to a way for a skilled user to wrest control in very specific cases) is the more disk-hungry than binary-focused distribution. On a more practical level, the capacity issue is somewhat moot. Hypothetically, an ISV offering a complex app for Linux, Mac and Windows would probably feel the most pressure to "include the kitchen sink" in the Linux version precisely because they have no assurances as to the features of the host Linux systems, whereas the Mac and Windows version can be smaller due to those environments being more predictable. I believe this even shows when you compare the sizes of apps like Firefox, Skype and OpenOffice. (Mozilla gave up on packaging Firefox for Linux, offering a plain 'drop it in/usr' binary with no dependency information; Firefox packages that we normally use come from our distros not Mozilla.)
My theory about users (which relates to experience) is that average users will always buck you in the end if you recommend a suitable Linux system that nevertheless makes their power-user friends feel helpless. Linux has to recreate some of the Mac/PC social evolution in order to offer a true desktop alternative: The PC catered to power users first and foremost, while the Mac started with a simple-user focus and migrated toward accommodating power-users (somewhere between the hypercard and applescript days is when the Mac made this transition). Otherwise, we tend to come off as dusty and irrelevant Unix priests, seemingly unable to do half of the wizardly feats that power-users apparently have mastered with their mix of commercial, shareware and FOSS. We are also unable to make many tasks go 'click' in the novice's head, because what we have to show them is a lot less consistent in terms of GUI semantics (sometimes with no GUI at all). Its like being on Ubuntu and showing them Firestarter because no integrated Control Panel front end exists, and then showing them how to execute an iwconfig script in the CLI because the Control Panel supports wireless, except for certain common features like WPA. Then from there you move onto KNetworkmanager, because there's no inbuilt way to detect/switch access points easily. What a jumble.
Perhaps you see already where I'm going with this... that eventually lightweight sysadmin duties (like enabling the firewall, or changing screen res) will have to have standardized control panel UI components in order for professionals to regard Desktop Linux as supportable. So the next question is: How are we turning-away young would-be sysadmins? Yes they will eventually need to handle/etc directly... but is it wise for LSB to leave vi as the only must-have editor, forcing inst
I think a lot of people are overlooking the fact that managing PC-like hardware as thin clients (using either Linux or Windows) does not mean they qualify as "PCs". The thin client experience of having little-or-no control over the software and data on your desktop is not really a part of the PC movement, which championed user-installable software (and even sneakernet) over networked terminals and centrally-controlled software.
People eventually brought PCs into the home because they felt like they had some control when using them at work. When their "DP" department was beng recalcitrant/lazy, they could use PCs to end-run around the mainframe culture.
A thick client is somewhat more 'personal', having significant local data storage.
In any case, Linux advocates shouldn't necessarily look to these municipal and corporate desktop conversions as a large-scale expansion of OSS into PC operating systems and culture. We should continue to ask whether a common platform for personal computing has emerged, one that facilitates independant (non-repository) software distribution on CDs and single downloadable files. Otherwise, Linux terminals might come to be synonymous with cost-cutting measures that can stifle worker innovation, suitable for people with menial jobs like cashier or data clerk.
Why should we ignore or seperate power users (the kind of person who would run PartitionMagic) from the rest? They are extremely influencial in getting their colleagues, family, etc. to adopt new things. Linux turns-off the power user more than any other, because they want personal control yet don't fit either the fulltime sysadmin role or the spoonfed-user role.
Gimp is no replacement for Photoshop. Besides the poor documentation and the GUI/menu layouts determined by the internal organization of code (instead of the kinds of tasks the user may be undertaking)... there's the lack of real white balance, no CMS, 24-bit limitation, etc, etc.
I'm also not sure if you missed the part that I was agreeing with you on, which was that all the interdependance causes dependancy hell. This is not the fault of the RPM, or the Deb package managers, it is the programmers who decide to incorporate system libraries in their code.
I appreciate that we agree for the need of standard desktop-focused libraries. But I may not agree with your reasoning, and its interesting to discuss: Why should anyone be punished with depedency issues just because an app uses "system" libraries? And if they're "system" libraries, then why aren't they installed by default? If they can't be counted on being in the system, then don't call them "system" libraries; call them "extras" instead and don't let them interfere with system updates or app installations.
Also, how common is it that apps that try to supply, internally, every library they need? Right down to the bare kernel? There is a balance to be struck on every platform, between being overly feature-rich and stark efficiency/simplicity lacking in versatility. Linux distros refuse to make an effort WRT that balancing act; They don't want to commit. Mac and Windows systems come with rich functionality, slowly becoming richer over time as Apple and MS take notice of what becomes popular with users and developers. If a few developers here and there don't want to use certain offerings in the platform, they can incorporate their own code in those specific cases.
So, why do Linux people (of which I am one) tend to think that including standard functionality (a defined platform) at a med-high level translates into a situation where developers have to "include all libraries themselves". Huh? It makes no sense.
I'm not pointing the finger solely at distro maintainers: It's the *process* that our community of elites has rallied around. We can't reasonably expect the general public to be able to use this for personal computing (thin clients, yes; PCs no).
I'm a certified Linux admin with a programming background. I know exactly what RPM files, repositories and package dependencies are. Together they comprise a web-like centralized database of interdependant linkages, and to extend enforcement of that system amorphosly beyond the core OS into "extra" features and applications is wholly inappropriate to facilitating independant software distribution for PCs. And by your own description a curious beginner must learn and wrangle with this beast before even getting to "show and tell", although I can assure you her curiosity probably doesn't extend to repositories and package managers. Instead we are obliged to, gently or otherwise, throw "RTFM" at her.
Which is why you won't see people like her writing compelling titles for Linux later on. Bet you can find her at MSDN or ADC though.
Between the different sound servers, you will probably be able to find something that allows your strange, non-standard sound card to run.
LOL! How can a Linux advocate point a finger at "non-standard" sound cards when our OS doesn't offer a standard API for audio? Why is the burden of standardizing always on someone OTHER than the Linux distro? RedHat, Novel, Canonical and all their community counterparts distribute audio software that use either AlSA or OSS/dev/dsp which is odd because the two are mutually-exclusive without using la
First, I was talking about average PC users, you know the people that use their computers to watch movies and listen to music, do homework, balance a checkbook and enjoy the internet.
Yes, on the surface. But there are too many influential PC users (or 'power users) who would not be drawn to the OS without titles like Photoshop, a Quicken, etc. that are polished and inspired.
If RPMs are so great, where are the apps I can download and install in a single RPM file?
And man pages are, of course, insufficient to address the differing lanscape that each distro presents. In some cases, the system will just blurt out which dependencies will have to be chased-down; in other cases, the system may attempt to fetch them but have some incompatible package names and numbering. Just why a 3rd-party application should carry a list ordering which parts of my OS should be installed and upgraded (even downgraded) is beyond me... keep your apps away from making decisions about my OS!
RPM/DEB + Centralized Repository + Repository Priest == a putrefying tarbaby that promises many hours of hardship and entanglement. Its not really better than the Windows registry. It inappropriately puts my OS components on an equal footing with user-selected services and apps, erasing the usual demarcation between them. It pressures everyone who uses it to filter their whole computing experience through a centralized software database. It puts important presentation, configuration and compilation options in the hands of Repository Priests who scarcely understand most lightweight GUI apps, nevermind the larger more involved ones.
This sort of infrastructure is appropriate for automatically updating operating systems. But it has been misapplied to cover "everything else". The result is not so much an OS or a platform, but "distributions" that have each been rolled into a large metastacized mass. Want to install a PDF viewer? Install Nautilus + its CD burner first! Bleh.
You would have a point about Mac OS if this sub-thread were dealing with hardware drivers. The way you drag-n-drop an app to install it on a Mac has nothing to do with hardware support. It deals with the standard set of modules/APIs that app developers know are always going to be there.
Third, why would there be any issue in running code from one box to another? If she and her friends were into linux, then they might also be farmiliar with source code compilation.
This is a question of inexperience, which I don't begrudge. App developers are primarily concerned with the surface APIs of the platform they build on. Cumbersome requirements that pull you under the surface to re-compile and rearrange at the system-level can and does drain away precious time, energy and enthusiasm. The only sort of enthusiasm that sort of thing encourages is for systems coding, which is almost a whole other field and attracts a different sort of programmer.
Someone with a yen for producing stimulating AV interactivity and simulated player intelligence is simply not going to get turned-on by ways to optimize data pipes and disk-buffering routines or ways to save 6MB by relying on a repository for certain libraries, or how to choose between ALSA/ESD/ARTS/OSS sound interfaces under differing circumstances... So DON'T put them in a position where they're forced to learn it! It's crap to them, and you shouldn't believe otherwise even for a second.
Yes, Linux does spur enthusiasm for systems coding/hacking. Unfortunately, it tends to take the form of trying to impress one's peers (other system-coders) so that features taking real consumer use-cases into account are relatively rare. Not only are use-cases unknown/ignored, but the concept of making committments to end-users is avoided like the plague. And with no general ethic of committing to users through softare design, we leave users confused and techies (also somewhat confused) unwilling to do tech support outside of casual easy-come-easy-go settings.
Slashdot Mirror
http://lwn.net/1998/0924/
Sorry, I didn't quote the URL in the parent post (so slashdot removed it).
From 1998, this article describes how Intel was eager to have Linux support UDI, the Uniform Driver Interface.
A lot of water has gone under the bridge since then, but UDI seemed to get submerged.
If Blair, Chirac, Putin, etc. were staying on a cruise ship but suddenly Bush had to stay at a military installation instead of joining them to avoid the possibility of Bin Laden crashing airplanes into the conference (hence the anti-aircraft missiles at the airport)... shouldn't that make an impression on Dear Leader? Someone in the administration took the threat seriously at Genoa in July: That is a fact. Had I been shifted to military accommodations, I would have known there was a threat - anyone would.
Then seeing a briefing titled "Bin Ladin Deteremined to Strike in US" a few weeks later elicited no response from Bush, even knowing that Bin Laden had struck the US at least twice on the past (USS Cole and the basement of the WTC).
To me, he looks like a coward who went on a very long vacation away from Washington, DC in order to avoid getting whacked.
Thank you for being a mac fanboy, nothing to see here, move along...
That's kind of a bizzarre leap.
Actually when I wrote that, I was thinking of how apps like Firefox have become primarily focused on Windows.
I agree the "Linux" misnomer is quite awful. As platforms go, its really more of a mass hallucination.
OTOH for basic functionality, the LSB seems as meaningful as "BSD". In a couple of months, we will also have the LSB Desktop spec (to include APIs like Gtk+ and Qt allowing developers to target desktop users, but without the KDE/Gnome desktop layer itself).
The Webmail extension for Thunderbird can access Yahoo Mail and also updates regularly. However its so easy to update extensions that I don't mind.
If you want Yahoo-->IMAP, just setup an IMAP server (or an account with a provider like Fastmail) then setup a TB rule to move the Webmail onto your IMAP server.
They're encouraging developers to think, "Ooh shiny! I want!"
How this is any more special then authenticating over TLS/POP3 is anyone's guess at this point. But I'll speculate that this is a way to entice developers to use Yahoo as a defacto authentication service as MS Passport aimed to be.
Personally, I think users have moved on. Our browsers remember our passwords, and its not hard to synchronize password DBs between browsers if you use more than one.
Think of this Yahoo authentication "openness" as a counterweight to the Google browser-sync tool. I prefer the Google idea, since Google only ever gets my browser data in encrypted form whereas Yahoo-as-authentication-server means that a breakin or abuse of the password DB == users getting screwed.
I want to know what makes Firefox a part of the OS in Debian's eyes, such that they are imposing these policies. What is this Debian product that lists Firefox as an integral feature?
:-) Or the Giant Ameboa From Outerspace.
If the answer is that every application in the Debian repositories gets reworked at-will by Debian, with no thought to misrepresenting identities, then what they're offering is no so much an OS as Katamari Damaci.
The FOSS community needs to start discussing which classes of software needs weak identity to aid innovation, and which need strong identity for the users' sake. We also need to start drawing a visible line between the OS and auxiliary applications, because most user-facing applications need different policies than OS components.
The confusion is similar to other Linux-based distros, only manifesting more strongly in this case:
What is the OS and what are the "Extra apps"?
Does this mean Firefox is part and parcel of the OS, and if so then why is the whole domain of GUI stuff treated as extras? If not, then why the urgent need to impose their tweaks on those programs?
I keep getting the impression they don't want to have a clear policy on desktop use, reworking applications, trademarks, etc, so they just switch between different attitudes as each situation suits them. In the case of DCCA distro using "Debian" in their name, Debian enforced their trademark against the former. Huh?
Mozilla foundation enforces the trademark on Firefox & Thunderbird. They come from a corporate background (what was Netscape) and have considerable user-focus. Part of the focus means the exact handiwork they produce and support is clearly identifiable by the end-user.
StarDivision -> OpenOffice.org reflects a similar tradition.
OSDL seems much looser with "Linux". Vendors are allowed to say "Mambo Linux", as if they took the kernel, painted it a different color, added leather seats, and offered a re-worked kernel for direct use by the end-user. Meanwhile anyone who can recompile a kernel encourages this identity-abuse. But most of what the user is getting is NOT Linux... It's the GNU toolchain plus a massive amount of higher-level stuff that could theoretically be standardized into consistent a PC platform. Can the end-user clearly identify the "Linux" product when they want to try a new OS? Of course not... Nor can they "use Linux" directly, so it has little meaning to most people. "Linux" is a complete misnomer in this context, like telling shoppers to go into a car dealership and say "shifter" when inquiring about complete automobiles. OSDL/Linux comes from a decidedly informal coding or 'hacking' tradition, and still accommodates confusion about product identities.
So, some projects insist of trademark integrity (much) more than others. Frankly, I do not think OSDL should allow distros to refer to their automobile as a "shifter". In many cases even GNU/Linux is inaccurate, like saying "shifter+transmission", so Stallman et al aren't so clever or correct on this point.
The FOSS developer community does make design committments to end-users, when it comes to certain products like "Firefox" or "Truecrypt"... but those serving in the "Linux" namespace avoid such committments like the plague; they are there to impress and commit to their peers for the most part.
I'll close with this: "Linux" advocacy is usually an excercise in misleading users by implying there is some committment to a platform product at a level they can use and identify (though the avg user cannot use or identify a mere kernel). Hackers and techies think they are doing something that will be meaningful/recognizable to the end-user over the long term, when this is rarely the case. Firefox advocacy doesn't have this problem; If it did, Mozilla would only write Gecko, and the browsers based on it would be called "Gecko distros", having considerably different UIs, collectively claim less than 2% marketshare, and extension-writers couldn't reliably anticipate which API functions would be included.
All 3 Maxtor drives I've owned have failed within a year. I won't buy another.
"The British public does not want parliament screwing up the only broadcaster left who actually cares about their viewers, instead of their advertisers."
That is not to say they won't ever try to put one over on the British public.
Here in the USA, we have PBS which is beholden to the federally-funded CPB and is chock-full of sponsorship announcements/ads. The result is a particularly pallid, toothless news bureau. We occassionally see informative and critical programming in the form of NOW or Frontline, but it is not "news" and always comes months too late for people to do much of anything preventative. NPR (radio) is structured the same, although their news is quite popular mainly because it is peppered with novel aesthetics and many affiliates air the BBC World Service (to make up for all the NPR mistakes and omissions) immediately afterward.
IOW we have here a perfect model for a neoliberal "modernised" public broadcaster that is right up Blair/Brown's alley. Do not be surprised if you discover this is already the government policy.
Nano is very tiny, and could be added to the LSB with absolutely no trouble. Then one could say that anytime you hop onto a Linux system, you can choose nano if vi seems too arcane. From there, realizing that OS X also includes nano, it is not a stretch to say that nano would be emerging as a *nix standard. It is already used in most OS X examples as a common-sense way to do quick edits in the CLI.
/etc stuff with XML files, making sure that a good text-mode XML editor with tree/node view was included. Too many subsystems on Linux integrate poorly because their config/control options are based on their /etc file, a custom format with vague rules and/or poor documentation. The first nonsense file format to be slayed would be xorg.conf. But that's just daydreaming. :-)
a rdware-compatibility-lists-hcl/
The problem with vi is that to many people it is outright repulsive. When told to use it, I infer an underlying attitude of "We don't care about making you deal with unnecessarily arcane tools and formats". Still, I'm not saying it should be abandoned or removed... its just not a program that ought to be forced onto anyone at the 'Webhosting 101' or 'Junior Linux Admin' stages.
Sed and awk are fine the way they are, but people are not going to be expected to learn them just so they can perform rare, emergency system maintenance. With vi, its a different story.
That is how I see it anyway. If it were up to me, I would replace 80% of
Your idea about relocating libraries for certain app dependencies reminds me of Apple appdirs: The non-standard version of the library stays in the appdir, and appropriately the vendor that supplied it with the app is responsible for how well it functions. I think that should be standard procedure when developing any app on any OS: If you insist on holding back to an older version than the OS specifies, then (if licensing allows) it is your job to include it with the app and have the app load it from its own folder. Making the rest of the system deal with your decision is just wrong, but unfortunately that's how its done on "Linux".
The HCL idea has been burning in my mind for over a year. If I could figure out a way to attract a real following (and some hardware expertise) to it, I'd set up a project website. Probably the first thing to do would be to compile information from the various fragmented hardware lists; these would be some starting points:
http://mradomski.wordpress.com/2006/07/09/linux-h
http://www.linux.org/vendor/hardware/index.html
http://support.xandros.com/hcl.php
And that earth-shattering question: What to call it?
I'm with you. Having seen the difference between BBC content and the crap available here I think the results are in: state-funded broadcasting works better and costs less.
The BBC isn't state-funded. It's a public corporation funded by a flat amount that each viewer pays in the form of a license fee.
Its amazing how many people just don't get it:
Since an organization's revenue stream will ultimately determine its biases, the BBC is funded independantly of the tax system. Charging a license fee in a "one-viewer-one-vote" fashion avoids conflicts of interest in covering both the private sector and state affairs. This helps dispell greed and political interference in how it goes about its job.
If the BBC received significant funds from tax revenue, then it would be a state-controlled broadcaster.
If they scaled the fee according to an individual's means, then their bias would slant toward serving the interests of the wealthy (which is what many anti-licensing activists very badly want).
A flat fee may not be a good model for many services. But for an organization that is supposed to serve the entire public without bias, to reflec that society which it serves, and to serve as a watchdog, IMO you cannot do better.
By just being in the wider broadcasting market, they change it for the better.
Yet even FOX News is typical of the coverage on Iran. They repeat deliberate mis-interpretations of what Iranian leaders say, and the scare over "wipe Israel off the map" is no different than the one about Iran legislating a dresscode for Jews. In the former case, we had the Iranian president saying that the Zionist regime must disappear from the page of time. Since Zionism can objectively be considered similar to Apartheid in crucial respects (not the least of which are its results).
I won't condone Iran's (or Israel's) theocracy, regardless of the particular style. Their involvement with Hizballah is questionable. But they are not a bunch of complete extremists. Iran is a country where women can get an education, show their faces, drive cars, and have access to birth control (compare that to our fascist allies, Saudi Arabia and Pakistan). Iran has a limited, nascent form of democracy and a great deal of technical sophistication.
They are independant of the West and that fact lands them squarely on the "must demonize" list. Iran is targeted for dehumanization all the more for its relative modernity, which gains them moral and cultural influence that makes it difficult for the West to propagandize the Middle East.
For our "civilized" western media, railing against a Zionist regime is eagerly mis-interpreted as a genocidal rant against Jews and an entire country. AND they do this at a time when the US is floating the idea of a "preventative" war and nuclear attack on Iran. Meanwhile, in the middle of all this self-righteous hyperventilating, our leaders get carte blanche to lie and spill vast amounts of blood elsewhere.
RMS is certainly correct when he says that free software would not put you in such a corner.
OTOH, you were really asking for it by expecting a whole-number upgrade to remain compatible with 3rd-party stuff. Even novices are supposed to understand that major whole-number upgrades are mostly likely to break compatability with previous versions as well as 'accessory' products and such.
They defended it in 2005 when Debian Common Core Alliance had to change their name to just 'DCCA'.
Whenever I scratch a lotto ticket, it's "supposed" to be a winner. Modern Americans are nothing more than smug, fat, indolent and apathetic consumers, who serve no purpose other than to feed cash into the system.
You forgot the petrodollars that keep the whole thing energized. The more fossil fuel we consume, the more dollars we get to print and send to foreign countries in return for stuff. It wouldn't be so dishonest if all the fuel were all ours to begin with. The more we chase that cashflow, the greater the imperative for the US government to acquire oil&gas flows for its chartered energy interests. The real costs in efficiency, human life and environment tend to be ignored in the whole destructive cycle.
Least of all, don't do anything that would dry-up the ocean of desperation that corporations rely on for cheap labor. Empowering women with family planning and birth control options is incompatible with the "culture of life".
The things I don't agree with are the Core Desktop thing and apps not using system wide libraries. To me the idea of merging everything and filtering it down into one unit seems like a daunting task.
/usr/src. That would seem to indicate over-reliance on source code as mere distribution vehicle (as opposed to a way for a skilled user to wrest control in very specific cases) is the more disk-hungry than binary-focused distribution. On a more practical level, the capacity issue is somewhat moot. Hypothetically, an ISV offering a complex app for Linux, Mac and Windows would probably feel the most pressure to "include the kitchen sink" in the Linux version precisely because they have no assurances as to the features of the host Linux systems, whereas the Mac and Windows version can be smaller due to those environments being more predictable. I believe this even shows when you compare the sizes of apps like Firefox, Skype and OpenOffice. (Mozilla gave up on packaging Firefox for Linux, offering a plain 'drop it in /usr' binary with no dependency information; Firefox packages that we normally use come from our distros not Mozilla.)
/etc directly... but is it wise for LSB to leave vi as the only must-have editor, forcing inst
Some misunderstanding here I think: When I say 'core desktop' I mean core APIs that ISVs would use to target a broad desktop audience. For example X11, gtk+, qt, dbus, etc. I am not referring to an actual Gnome or KDE desktop.
I dislike man pages on Linux because 1) they sometimes say 'use info instead', and 2) they almost always omit examples. BSD is much nicer for 'man' and its one of the reasons I have grown to like OS X so much in the past 18 months since I bought a Mac.
As far as different applications bundling the libraries in with them, I have a feeling there might be some legal issues with that,
Indeed, independant commercial developers wouldn't be able to statically link GPL stuff for starters. All the more important that devs have assurance certain libraries will already exist in the system (even better if their program only has to check which LSB level the system is at).
A 12GB root seems very large to me. I notice my root tends to expand greatly when I've got a lot going in
My theory about users (which relates to experience) is that average users will always buck you in the end if you recommend a suitable Linux system that nevertheless makes their power-user friends feel helpless. Linux has to recreate some of the Mac/PC social evolution in order to offer a true desktop alternative: The PC catered to power users first and foremost, while the Mac started with a simple-user focus and migrated toward accommodating power-users (somewhere between the hypercard and applescript days is when the Mac made this transition). Otherwise, we tend to come off as dusty and irrelevant Unix priests, seemingly unable to do half of the wizardly
feats that power-users apparently have mastered with their mix of commercial, shareware and FOSS. We are also unable to make many tasks go 'click' in the novice's head, because what we have to show them is a lot less consistent in terms of GUI semantics (sometimes with no GUI at all). Its like being on Ubuntu and showing them Firestarter because no integrated Control Panel front end exists, and then showing them how to execute an iwconfig script in the CLI because the Control Panel supports wireless, except for certain common features like WPA. Then from there you move onto KNetworkmanager, because there's no inbuilt way to detect/switch access points easily. What a jumble.
Perhaps you see already where I'm going with this... that eventually lightweight sysadmin duties (like enabling the firewall, or changing screen res) will have to have standardized control panel UI components in order for professionals to regard Desktop Linux as supportable. So the next question is: How are we turning-away young would-be sysadmins? Yes they will eventually need to handle
I think a lot of people are overlooking the fact that managing PC-like hardware as thin clients (using either Linux or Windows) does not mean they qualify as "PCs". The thin client experience of having little-or-no control over the software and data on your desktop is not really a part of the PC movement, which championed user-installable software (and even sneakernet) over networked terminals and centrally-controlled software.
People eventually brought PCs into the home because they felt like they had some control when using them at work. When their "DP" department was beng recalcitrant/lazy, they could use PCs to end-run around the mainframe culture.
A thick client is somewhat more 'personal', having significant local data storage.
In any case, Linux advocates shouldn't necessarily look to these municipal and corporate desktop conversions as a large-scale expansion of OSS into PC operating systems and culture. We should continue to ask whether a common platform for personal computing has emerged, one that facilitates independant (non-repository) software distribution on CDs and single downloadable files. Otherwise, Linux terminals might come to be synonymous with cost-cutting measures that can stifle worker innovation, suitable for people with menial jobs like cashier or data clerk.
10.4 Tiger also uses 0.9.7i, which, as you'll note, was not listed as among those versions affected.
Then Tiger is indeed affected, because 'i' comes before 'j'. Read the advisory again.
Oh, come on now...
:-)
What if she writes them in Python or Ruby?
You didn't assume I was talking about C, did you?
Why should we ignore or seperate power users (the kind of person who would run PartitionMagic) from the rest? They are extremely influencial in getting their colleagues, family, etc. to adopt new things. Linux turns-off the power user more than any other, because they want personal control yet don't fit either the fulltime sysadmin role or the spoonfed-user role.
/dev/dsp which is odd because the two are mutually-exclusive without using la
Gimp is no replacement for Photoshop. Besides the poor documentation and the GUI/menu layouts determined by the internal organization of code (instead of the kinds of tasks the user may be undertaking)... there's the lack of real white balance, no CMS, 24-bit limitation, etc, etc.
I'm also not sure if you missed the part that I was agreeing with you on, which was that all the interdependance causes dependancy hell. This is not the fault of the RPM, or the Deb package managers, it is the programmers who decide to incorporate system libraries in their code.
I appreciate that we agree for the need of standard desktop-focused libraries. But I may not agree with your reasoning, and its interesting to discuss: Why should anyone be punished with depedency issues just because an app uses "system" libraries? And if they're "system" libraries, then why aren't they installed by default? If they can't be counted on being in the system, then don't call them "system" libraries; call them "extras" instead and don't let them interfere with system updates or app installations.
Also, how common is it that apps that try to supply, internally, every library they need? Right down to the bare kernel? There is a balance to be struck on every platform, between being overly feature-rich and stark efficiency/simplicity lacking in versatility. Linux distros refuse to make an effort WRT that balancing act; They don't want to commit. Mac and Windows systems come with rich functionality, slowly becoming richer over time as Apple and MS take notice of what becomes popular with users and developers. If a few developers here and there don't want to use certain offerings in the platform, they can incorporate their own code in those specific cases.
So, why do Linux people (of which I am one) tend to think that including standard functionality (a defined platform) at a med-high level translates into a situation where developers have to "include all libraries themselves". Huh? It makes no sense.
I'm not pointing the finger solely at distro maintainers: It's the *process* that our community of elites has rallied around. We can't reasonably expect the general public to be able to use this for personal computing (thin clients, yes; PCs no).
I'm a certified Linux admin with a programming background. I know exactly what RPM files, repositories and package dependencies are. Together they comprise a web-like centralized database of interdependant linkages, and to extend enforcement of that system amorphosly beyond the core OS into "extra" features and applications is wholly inappropriate to facilitating independant software distribution for PCs. And by your own description a curious beginner must learn and wrangle with this beast before even getting to "show and tell", although I can assure you her curiosity probably doesn't extend to repositories and package managers. Instead we are obliged to, gently or otherwise, throw "RTFM" at her.
Which is why you won't see people like her writing compelling titles for Linux later on. Bet you can find her at MSDN or ADC though.
Between the different sound servers, you will probably be able to find something that allows your strange, non-standard sound card to run.
LOL! How can a Linux advocate point a finger at "non-standard" sound cards when our OS doesn't offer a standard API for audio? Why is the burden of standardizing always on someone OTHER than the Linux distro? RedHat, Novel, Canonical and all their community counterparts distribute audio software that use either AlSA or OSS
First, I was talking about average PC users, you know the people that use their computers to watch movies and listen to music, do homework, balance a checkbook and enjoy the internet.
Yes, on the surface. But there are too many influential PC users (or 'power users) who would not be drawn to the OS without titles like Photoshop, a Quicken, etc. that are polished and inspired.
If RPMs are so great, where are the apps I can download and install in a single RPM file?
And man pages are, of course, insufficient to address the differing lanscape that each distro presents. In some cases, the system will just blurt out which dependencies will have to be chased-down; in other cases, the system may attempt to fetch them but have some incompatible package names and numbering. Just why a 3rd-party application should carry a list ordering which parts of my OS should be installed and upgraded (even downgraded) is beyond me... keep your apps away from making decisions about my OS!
RPM/DEB + Centralized Repository + Repository Priest == a putrefying tarbaby that promises many hours of hardship and entanglement. Its not really better than the Windows registry. It inappropriately puts my OS components on an equal footing with user-selected services and apps, erasing the usual demarcation between them. It pressures everyone who uses it to filter their whole computing experience through a centralized software database. It puts important presentation, configuration and compilation options in the hands of Repository Priests who scarcely understand most lightweight GUI apps, nevermind the larger more involved ones.
This sort of infrastructure is appropriate for automatically updating operating systems. But it has been misapplied to cover "everything else". The result is not so much an OS or a platform, but "distributions" that have each been rolled into a large metastacized mass. Want to install a PDF viewer? Install Nautilus + its CD burner first! Bleh.
You would have a point about Mac OS if this sub-thread were dealing with hardware drivers. The way you drag-n-drop an app to install it on a Mac has nothing to do with hardware support. It deals with the standard set of modules/APIs that app developers know are always going to be there.
Third, why would there be any issue in running code from one box to another? If she and her friends were into linux, then they might also be farmiliar with source code compilation.
This is a question of inexperience, which I don't begrudge. App developers are primarily concerned with the surface APIs of the platform they build on. Cumbersome requirements that pull you under the surface to re-compile and rearrange at the system-level can and does drain away precious time, energy and enthusiasm. The only sort of enthusiasm that sort of thing encourages is for systems coding, which is almost a whole other field and attracts a different sort of programmer.
Someone with a yen for producing stimulating AV interactivity and simulated player intelligence is simply not going to get turned-on by ways to optimize data pipes and disk-buffering routines or ways to save 6MB by relying on a repository for certain libraries, or how to choose between ALSA/ESD/ARTS/OSS sound interfaces under differing circumstances... So DON'T put them in a position where they're forced to learn it! It's crap to them, and you shouldn't believe otherwise even for a second.
Yes, Linux does spur enthusiasm for systems coding/hacking. Unfortunately, it tends to take the form of trying to impress one's peers (other system-coders) so that features taking real consumer use-cases into account are relatively rare. Not only are use-cases unknown/ignored, but the concept of making committments to end-users is avoided like the plague. And with no general ethic of committing to users through softare design, we leave users confused and techies (also somewhat confused) unwilling to do tech support outside of casual easy-come-easy-go settings.
Seems they haven't yet issued an update for Mac OS X Panther (which has OpenSSL at 0.9.7i).