I also know that debunking one, does nothing to debunk every claim. It is a hopeless crusade based on flawed logic and knee-jerk reactions to the world.
It does, however, raise the standard of proof.
Think about what you are saying:
Wether it is by warmth, by some exotic particles, by quantum potentiality or brute-force and trickery, I know still that what happened is perfectly natural.
Correct. This is the Hume philosophy, in essence.
However, what Randi does is, he guesses at the method by which something might be tricked. He then sets up an environment such that this particular method of trickery is impossible, or at least detectable. And then...
And then, every time, the "psychic" backs out. (Or doesn't respond at all.)
For instance: Take Uri Gellar and his spoon-bending. James Randi was called to help prevent trickery, and he did so by suggesting that they provide their own props -- their own, un-tricked spoons. And of course, Gellar says "I don't feel powerful today."
So if he was using brute-force or a pre-bent spoon, or some other, well-understood method of physical trickery, then he is a fraud, because he claimed to be bending it with his mind. If he did bend it with some exotic particles, quantum potentiality, or some other either not-discovered natural law/phenomenon, don't you think that would be an interesting thing to know about?
James Randi's prize, of course, is incompatible with that worldview -- if he can prove you're doing it through natural means, and not "supernatural" means (meaning he can't figure out how you might be doing it), then you don't get the prize. However, I would think that you could earn a great deal more than $1m through the patents alone if you (and James Randi) did discover something entirely new.
Btw, sceptics never ever came up with a new discovery.
On the contrary, I'd say they do all the time.
Think back to any great scientist you know by name. Do you think they believed in something for which they had no proof? In other words, do you think they believed in the supernatural?
Of course, their hypotheses might've been supernatural, but they've been proven.
Error correction on a physical channel that's transmitting digital data works by "guessing" what the most likely transmitted symbol is, and it's not outside the realm of possibility that the algorithm guesses wrong.
Except it's my understanding, though I may be entirely wrong, that the encryption makes this impossible -- that errors would involve in the HDMI signal being reset.
Reading this article just pissed me off. Let me count the obvious mistakes:
Because Dell does not have to pay a licensing fee for the operating system, the computers are $80 cheaper than PCs with Windows Vista Home Premium or $50 cheaper than the stripped-down Vista Basic edition.
Maybe I haven't been looking in the right place, but you can't simply select Windows or not in the customize page, which makes it a lot harder to do these comparisons. Often, I find that while there is a Linux model that's cheaper than the Windows model, there's also a separate, crappier Windows model that's even cheaper, for which there is no Linux model.
Or maybe it's changed recently, too.
It took me only seconds to find several additional music players, a PDF reader and other programs.
The standard Ubuntu doesn't come with one?
Weird, because Kubuntu comes with kpdf.
or you can boot from the CD to test-drive the operating system on a Windows machine or an Intel-based Mac, without having to install or delete anything.
While that's true if you stick to the 32-bit Intel version, there is also a 64-bit version, which will only work on the newer Windows machines or Intel-based Macs -- and which, were it not for Flash, would be the obvious choice for them.
But he's also ignoring the PowerPC version, which pretty much makes any Mac capable of running Ubuntu. There's also, apparently, an Itanic -- sorry, Itanium version, which very likely is different than the amd64 version, and a PlayStation 3 version.
To me, that's one of the great selling points of Linux -- not Ubuntu, specifically, but the kernel as a whole has been ported to just about everything. In general, while you still want to do research for individual components, chances are, the overall architecture is supported -- you can run Linux on that old Powerbook, and probably will be able to for awhile. Will it run OS X Leopard? What about the next version? And it's certainly never going to run Windows natively.
To watch a movie, the Linux user must install necessary codecs, or decoders. One way to do that is to first download a program called Automatix from www.getautomatix.com.
Automatix was a temporary solution, and is depricated, and has been known to break systems. Use Medibuntu.
It is often difficult to figure out what files to download and in many cases you will have to burn those files to a CD or DVD. Windows users will need a commercial CD burning program or the free BurnCDCC (available at terabyteunlimited.com/utilities.html).
Most computers that have a CD burner also have software which is capable of burning a CD image, and if you attempt to download Ubuntu from Ubuntu.com, you're going to get a CD image. It's also really not difficult -- Desktop Edition, version 7.04 or 6.06 (really, is that hard?), standard personal computer (or 64-bit if you know you have it), and choose a location near you -- which could be made easier by defaulting to a US site, maybe, but it'll work no matter which you try.
And if you need burning software, you may as well get something open source -- I generally recommend InfraRecorder.
But since common tasks like watching a movie or syncing an iPod require hunting for and installing extra software
Watching a movie, I'll give you, although that's a common enough thing that you can pretty much just Google for "Ubuntu watch DVD" and find a site that gives you at least one way. Or, someone in the know can point you at Medibuntu, which pretty much does it all for you.
As for syncing an iPod... Maybe iPods, because they deliberately try not to interoperate. But every time I pop in a USB mass storage device with Amarok running, it asks me if I want to manage it as a music player. Now, that's Amarok, not whatever the stock GNOME/Ubuntu comes w
I'm not saying that it's at all possible for any human to detect the difference, but I suppose it's theoretically possible that if they are simply audio cables, there might be some measurable difference in the sound, even if no one could tell.
HDMI is where it's truly insane -- yeah, let's gold-plate a cable that transmit a digital signal. Digital is different -- either it worked or it didn't. HDMI even moreso -- if it didn't work, your entire audio/video is likely to cut out all at once, probably for a second or two, until it can be reestablished. If the video works at all, you have a good enough HDMI cable.
At the risk of flogging a dead horse, I would then have been talking about Celanor's experiences with preloaded Ubuntu, Dell or not. And I thought it was pretty obvious from context that I wasn't talking about his...
Anyway, yes, I was not as clear as I should've been.
Unless Dell (or Ubuntu) has done something different
Sure sounds like I'm talking about the Ubuntu I know, not the Ubuntu that comes on Dell.
Going back further...
Apparently, the Dell Ubuntu is a stock Ubuntu, with very few modifications -- some sort of EULA-like clickthrough, for example.
Ok, that was misleading.
I have not actually used the Dell Ubuntu, and I've never bought it. I have, however, talked to people who have used Linux and don't like it because of performance issues, and others because of lack of driver support -- both in situations where they either had no patience for Linux or no patience for technical problems in general.
Everything I know about the Dell Ubuntu is secondhand.
O.K. this is very hyperthetical - what if the 'flash system' became so widespread on the internet that *every* website needed it to function - You would have a virtual monopoly sitting right inside your system with no alternative!!??
That pretty much already exists for YouTube, unless someone's found a way to make it go into iPhone mode on a PC browser. But that only worked because Apple basically strongarmed them into providing mp4 files, instead of Flash.
There are plenty of projects like this -- a corporation owns all the copyrights, so they can dual-license under GPL and something else. Even projects like Gentoo do this with "foundations", not for a profit, but so they can switch licenses if they have to. This is generally considered preferable to leaving everything GPLv2 only (like Linux), making it impractical to switch to anything else, as you'd need consent from every contributor. It's also generally considered preferable to leaving it GPLv2 or later, which means the FSF can create a new license, and people can then relicense your code under the new license -- it basically means instead of the project controlling the license, the FSF does.
The problem is when you want to ensure that your own contribution will always be used exclusively for open stuff. So, some contributor insists on only GPL, which means there's going to have to be a fork. No way around it.
Since any copying is stealing, you're not even allowed to buy one copy for every device you want to listen on, because you'd necessarily have to copy it from your computer to the device -- perhaps from a CD to your computer to a device.
Yes, according to this bitch, iPods are illegal, unless filled entirely with free/open music -- if she even knows such things exist.
Wouldn't the "carbon footprint" be smaller if you just trashed them now?
Maybe not.
Assuming the people receiving these will have a computer anyway, better to keep the old one out of the landfill a bit longer. The power isn't much, compared to how much hardware is going into there. And you can get power for free (of environmental impact), sort of -- solar, wind, etc -- whereas you cannot get hardware for free.
Assuming the people receiving these would not have had a computer, that's a sociological win, but maybe an environmental lose. Generally, I prefer the sociological win, though it's hard to have a general policy -- I don't think we should club baby seals for just about any reason, but I do think everyone should have access to a computer and the Internet.
Based on vague rumor, memory, etc, I get the feeling that Google is doing something like this: Keep old hardware running as long as you can, it's just taking up space. When you need to expand the Google Grid, either get more space/power, or throw out the oldest hardware and replace it with brand new hardware. Also, probably tend to replace old, broken hardware with new, working hardware. I'm basically assuming that their grid is capable of being a heterogeneous environment.
Would it be more power-efficient to throw em away? Maybe, but they have an abundance of power -- I hear they are planning to build solar roofs over their parking lots, so that people with hybrid/electric cars can plug them in. Any extra power from that could just feed straight into the grid.
(All pure speculation -- I don't work at Google, and I have no more resources than the average Slashdotter to find out what goes on there.)
There's a difference between allowing duplication and requiring it.
Indeed. Nothing about the system I proposed requires more duplication than we have, except for people wishing to run a different filesystem as root.
NTFS is also notable as a filesystem that no one running Linux wants to use for a root filesystem. The same cannot be said of ext3, ext4, reiserfs, or even relatively obscure filesystems such as JFS or XFS.
That's a fair point, but then...
Are you saying that what people want should dictate these decisions? Because if so, it seems plenty of people want the pluggable scheduler.
Unlikely. Many people use reiserfs for their root filesystem. In fact, I believe it was the default in SUSE until recently.
In that case, they get to run a patched kernel, and maybe not get updates, until they can either find a bootcd with a tool for migrating their data in-place (difficult to write for any filesystem), or they can back all their data up and restore it.
I seem to remember that Minix was, at one time, supported by the kernel. And I believe it's been removed, so anyone who was still using the original Minix or ext has to upgrade to ext2. And I believe ext2 is format-incompatible, meaning they had to back up and restore, though I could be wrong about that. I'm fairly sure ext4 will be incompatible, though.
Understand, too, that I'm playing devil's advocate here. I'm perfectly happy with pluggable filesystems, although I'm not particularly happy that so much of the filesystem is in the kernel, or that context switches are slow enough that it makes sense for them to be there. I'm just using it as a basis for explaining why I think pluggable schedulers might be a good idea.
Although there was another reply, kind of buried by now, maybe, pointing out that CFQ is very tunable and supports somewhat more limited plugins of its own. That would suggest it's more like replacing the Linux VFS with Reiser4 (and implementing existing filesystems as Reiser4 storage plugins), although I wouldn't recommend that either now, as unstable as Reiser (filesystem and person) can be.
That would lead to major duplication of code. There would probably be a userspace implementation and a kernel implementation of every major filesystem.
Yeah. Sounds like ALSA/OSS.
In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.
Moreover, this is already true of every filesystem that I know of, to some extent. Remember that the userspace implementation need not provide everything the kernel implementation does -- even simple APIs to copy whole files in/out of the FS might be sufficient for most workloads.
But just how do you think mkfs.ext3 works? How about fsck.ext3? Or the various debugfs, dump, etc...
because they eventually want it to be a replacement for ext3 on root partition
More likely, they'd develop it as a replacement. They'd use UserMode Linux, and they'd probably start with the ext3 code, so ext4 need never be in a state such that it can't be used as a root FS, even if only for a disk image.
The same would likely happen for many other filesystems, such as reiserfs, as well.
More likely, ReiserFS would only be implemented in userspace. It's irrelevant -- using filesystems other than ext3 (or ext4) for your root filesystem is just wanking with settings, remember? You only need ReiserFS if some poor, uneducated soul happened to format their system with Reiser, then you have to use the userspace driver to back it up.
I imagine there are actually filesystems that have already moved to this level of support -- where the userspace utilities are really the only way of getting at the stuff, as all kernel support has been dropped.
Fortunately, there's still FUSE, but that's a big performance hit, and it does tend to invalidate your case against pluggable schedulers.
Or you get Gimp, or Krita, or Paint.NET... All more than enough for what we're describing.
Apple's iPhoto edits and displays photos, adds music and makes great slide shows and it's all included with every Mac. You can even make your own music with Garage Band, also included if the iTunes Library doesn't include that exactly right music for the show. All these programs are integrated with each other and Mac OSX.
Joe user won't be using Garage Band, and if he was, Linux has Ardour. What else about what you described is better?
Actually, it it is likely easier to make OSX run on a Dell than to fit a Honda engine into a Ford.
True. However, the latter is neither illegal nor actively prevented by either company, to my knowledge.
Consider something that is pluggable, then -- the radio. You don't take a radio out of one car, put it into the other, and have it refuse to work because it's not in a Ford. What's more, this would be considered unacceptable behavior.
Almost any thing can be done, with enough effort and expense.
So why does Apple spend so much effort and expense trying to lock their stuff down?
Of course they are. I only gave that example as one way of making things easy to use, so Joe User doesn't have to know what processor their Mac has.
Except it also means Joe User now has to wonder, sometimes, why his new Macbook runs some apps slower than his old Powerbook did.
And it has to be transparent for developers, not just users. UT2004 came with the Linux installers on the same disc as the Windows installers, so you don't have to think about it -- if you bought UT2k4, you have the version you need for either. (Not sure about the OS X version, but I've known OS9 and older Mac programs to be bundled on the same disc as the Windows version.)
However, I guarantee the actual work of porting was not easy. Thus, you don't see many discs like this, and users are surprised when stuff "just works". Xcode makes it easy to compile a "Universal Binary", but you still need to actually go buy each kind of machine to be sure, otherwise you're going to hit obscure bugs -- if you haven't already hit obscure compiler bugs.
Byte code languages have their own drawbacks. Speed was a big one in the past, but now that processors are so fast, it is less important. One still has to have the proper, current, Interpreter/compiler though. I have had Java programs error out with a message that this program needs version xxx to run.
I want you to go back and re-read that, but replace "byte code" with "compiled".
Speed was a big one in the past, but it's not because processors are so fast now. I'd still like to let my fans spin down and stop burning my lap now and then.
But consider: We used to think compiled languages were slower than assembly. Turns out, the gains from intelligent, optimizing compilers are huge -- big enough that only in very performance-critical apps do you even consider assembly, and there, you do it in very, very small amounts, and test thoroughly. You do this because the compiler is smart enough that you, as a human, could easily do a worse job translating than the compiler did.
Google for "A Plan for Spam" for an example of why, sometimes, we really ought to just let the computer do the work.
Bytecode engines can do runtime optimizations. A simple example: A bytecode engine can analyze a given function, or instruction, or whatever unit you want to use, and compile several different variants of it, each of which works better under different circumstances. Then, by actually looking at the real workload being used right now, it can figure out which one is better, right now. If the workload changes, it might use a different
If you buy an Nvidia, you have fine proprietary drivers that just need one click to enable.
Unless Dell (or Ubuntu) has done something different, to my knowledge, you still have to do this:
Open Synaptic. (Assuming you know where it is.)
Search for "nvidia".
Click on "nvidia-glx-new", most likely. Or maybe "nvidia-glx", or even "nvidia-glx-legacy". (I'm assuming you know the version of your card, otherwise that's at least 2-3 more steps.))
Click "Apply".
Close Synaptic when it's done. (This is likely several clicks.)
Open a terminal.
Type "nvidia-xconfig".
Log out. (Assuming this restarts X before you log back in.)
I know it's not hard. It's certainly easier to keep them updated. Hell, steps 6-7 might no longer be necessary.
But it's a far cry from "one click", especially for someone who just bought their first Dell with Ubuntu. And having to use the VGA drivers can slow the machine down a LOT, which means people walk away from the experience with either the opinion that Linux is only for those who know what they're doing (since you have to type confusing stuff into a terminal), or that Linux sucks, performance is awful, etc etc.
Unless I'm wrong, and Dell really has made it "one-click" and BLATANTLY obvious (along the lines of asking the user a question right after they agree to the EULA), I would almost rather they not sell Linux. At least if someone's installing it themself, they expect problems, but if they actually order a whole computer, they not only expect everything to be working, but they also will have invested money, and will have a very real sense of being ripped off.
As long as wireless and hibernation/suspend works out of the box
That'd be another no, and no.
Maybe it's just me, but I had to explicitly add a "resume=/dev/sda5" (or whatever) argument to my kernel commandline. And while my wireless worked out of the box, I have a friend who has the one broadcom card that isn't even supported with the native (bring-your-own-firmware) drivers, so I'm going to have to walk him through ndiswrapper.
On my own laptop, sound doesn't work out of the box either -- I'm probably going to have to get the CVS (or whatever it is these days) of the ALSA drivers to make it work, maybe.
I'll be the first to admit that the codec situation is bad, but no worse than the drivers. After all, mp3 works out of the box, right?
As for filesystems, there are so many filesystems that people do need that it would be crazy to try to support them all without modularity.
<sarcasm>They only think they need them. Really, they're just wanking around with their settings.</sacrams>
Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network, ISO/UDF, and FAT/NTFS, can be done in userspace -- see the various userspace VFS projects -- they don't have to be fast anyway, since they're generally removable media, or stuff rarely accessed. Anyone booting from the network is probably running a custom kernel anyway.
These are all arguments I've heard people use against pluggable schedulers, which don't make sense here. After all, you can't have two root filesystems at the same time...
As for sound, some systems don't even need sound, you need modularity to allow them to remove support for it.
And some systems don't need pre-emptive scheduling. And some of them could certainly do better with a round-robin scheduler, so that more time is spent crunching and less is spent deciding what to do.
The point is that the main kernel maintainers are deciding what's important and what's not. I don't know enough to understand whether it's seriously problematic to implement a pluggable scheduling system, but this does not get to be dismissed as "not important", and certainly not as "people just wanking with their settings". Multiple schedulers are necessary, in some form, even if they have to be in separate kernel forks.
Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.
True enough, or at least, they don't use a kernel compiled with vanilla options.
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
The whole point of wanting a pluggable scheduler is to let the end-user answer that "for what" question, instead of having Linus answer it for you, or have to use a fork.
I don't argue that it has to be pluggable at runtime, and though I haven't been following this, I suspect that "at runtime" is what would slow down the architecture. Because if it's just another menuconfig option, that slows down development, not execution.
No, Linus' point about schedulers is that to make a pluggable scheduler, you will need to sacrifice performance just to achieve the plug-ability.
If it had to be hot-pluggable -- as I believe some of these are -- then yes.
But just run "make menuconfig" and take a look at the insane number of options you have for compiling a Linux kernel. It seems to me that slapping some #ifdef statements around some code isn't going to make it perform any worse.
It might, however, be harder to maintain.
For one, the performance requirement does not exist.
In security? Yes it does!
I mean, yes, we'll often choose the more secure model over the better-performing one, but not always. Consider the performance implications of, for example, trying to predict every possible state a program could be in, so you could determine whether or not to run the program -- programs which might possibly do things they aren't allowed to never get run in the first place.
Obviously, we don't do that. We do the analysis at runtime -- when a program attempts to do something it's not allowed to, we block it then, we don't try to predict it happening.
And since there exist no metrics that can be used to determine whether one security model is better than another without the usage context, a plug-able architecture is the best road to go down to let something that users CAN and WILL want to implement completely differently from one use-case to the next.
Except from what I understand, SELinux and ACLs are a superset of traditional Unix security, and could, in fact, completely replace it (and emulate it). So why not make SELinux the only security architecture?
Slashdot Mirror
It does, however, raise the standard of proof.
Think about what you are saying:
Correct. This is the Hume philosophy, in essence.
However, what Randi does is, he guesses at the method by which something might be tricked. He then sets up an environment such that this particular method of trickery is impossible, or at least detectable. And then...
And then, every time, the "psychic" backs out. (Or doesn't respond at all.)
For instance: Take Uri Gellar and his spoon-bending. James Randi was called to help prevent trickery, and he did so by suggesting that they provide their own props -- their own, un-tricked spoons. And of course, Gellar says "I don't feel powerful today."
So if he was using brute-force or a pre-bent spoon, or some other, well-understood method of physical trickery, then he is a fraud, because he claimed to be bending it with his mind. If he did bend it with some exotic particles, quantum potentiality, or some other either not-discovered natural law/phenomenon, don't you think that would be an interesting thing to know about?
James Randi's prize, of course, is incompatible with that worldview -- if he can prove you're doing it through natural means, and not "supernatural" means (meaning he can't figure out how you might be doing it), then you don't get the prize. However, I would think that you could earn a great deal more than $1m through the patents alone if you (and James Randi) did discover something entirely new.
On the contrary, I'd say they do all the time.
Think back to any great scientist you know by name. Do you think they believed in something for which they had no proof? In other words, do you think they believed in the supernatural?
Of course, their hypotheses might've been supernatural, but they've been proven.
Except it's my understanding, though I may be entirely wrong, that the encryption makes this impossible -- that errors would involve in the HDMI signal being reset.
I could be entirely wrong, of course.
Reading this article just pissed me off. Let me count the obvious mistakes:
Maybe I haven't been looking in the right place, but you can't simply select Windows or not in the customize page, which makes it a lot harder to do these comparisons. Often, I find that while there is a Linux model that's cheaper than the Windows model, there's also a separate, crappier Windows model that's even cheaper, for which there is no Linux model.
Or maybe it's changed recently, too.
The standard Ubuntu doesn't come with one?
Weird, because Kubuntu comes with kpdf.
While that's true if you stick to the 32-bit Intel version, there is also a 64-bit version, which will only work on the newer Windows machines or Intel-based Macs -- and which, were it not for Flash, would be the obvious choice for them.
But he's also ignoring the PowerPC version, which pretty much makes any Mac capable of running Ubuntu. There's also, apparently, an Itanic -- sorry, Itanium version, which very likely is different than the amd64 version, and a PlayStation 3 version.
To me, that's one of the great selling points of Linux -- not Ubuntu, specifically, but the kernel as a whole has been ported to just about everything. In general, while you still want to do research for individual components, chances are, the overall architecture is supported -- you can run Linux on that old Powerbook, and probably will be able to for awhile. Will it run OS X Leopard? What about the next version? And it's certainly never going to run Windows natively.
Automatix was a temporary solution, and is depricated, and has been known to break systems. Use Medibuntu.
Most computers that have a CD burner also have software which is capable of burning a CD image, and if you attempt to download Ubuntu from Ubuntu.com, you're going to get a CD image. It's also really not difficult -- Desktop Edition, version 7.04 or 6.06 (really, is that hard?), standard personal computer (or 64-bit if you know you have it), and choose a location near you -- which could be made easier by defaulting to a US site, maybe, but it'll work no matter which you try.
And if you need burning software, you may as well get something open source -- I generally recommend InfraRecorder.
Watching a movie, I'll give you, although that's a common enough thing that you can pretty much just Google for "Ubuntu watch DVD" and find a site that gives you at least one way. Or, someone in the know can point you at Medibuntu, which pretty much does it all for you.
As for syncing an iPod... Maybe iPods, because they deliberately try not to interoperate. But every time I pop in a USB mass storage device with Amarok running, it asks me if I want to manage it as a music player. Now, that's Amarok, not whatever the stock GNOME/Ubuntu comes w
Those speaker cables look analog.
I'm not saying that it's at all possible for any human to detect the difference, but I suppose it's theoretically possible that if they are simply audio cables, there might be some measurable difference in the sound, even if no one could tell.
HDMI is where it's truly insane -- yeah, let's gold-plate a cable that transmit a digital signal. Digital is different -- either it worked or it didn't. HDMI even moreso -- if it didn't work, your entire audio/video is likely to cut out all at once, probably for a second or two, until it can be reestablished. If the video works at all, you have a good enough HDMI cable.
At the risk of flogging a dead horse, I would then have been talking about Celanor's experiences with preloaded Ubuntu, Dell or not. And I thought it was pretty obvious from context that I wasn't talking about his...
Anyway, yes, I was not as clear as I should've been.
Right. I am not Celanor.
Sure sounds like I'm talking about the Ubuntu I know, not the Ubuntu that comes on Dell.
Going back further...
Ok, that was misleading.
I have not actually used the Dell Ubuntu, and I've never bought it. I have, however, talked to people who have used Linux and don't like it because of performance issues, and others because of lack of driver support -- both in situations where they either had no patience for Linux or no patience for technical problems in general.
Everything I know about the Dell Ubuntu is secondhand.
Doesn't start in Konqueror. I get a gray screen, and if I check my Javascript error log, an error about some sort of type mismatch.
I'll have to look at it in Firefox later, but really, what is the excuse for not testing in every browser? At least to make sure it starts?
Neither of those were Dell, actually.
Sound, I'll give you, since had I bought the laptop myself, knowing it would be used for Ubuntu, I'd have done a bit more research.
If sibling posts have convinced you that ODF isn't a bad thing, maybe you could take a look at some of the other implementations.
There's the KDE Office, which is not bloated at all.
AbiWord, Gnumeric, etc make up a nebulous concept called the "GNOME Office".
I'm sure there are dozens of others -- you could always just go to Google Docs, for instance. But that should be enough to get you started.
How is that different/better than, say, Dojo? Or Google Web Toolkit, or Yahoo UI Library?
That pretty much already exists for YouTube, unless someone's found a way to make it go into iPhone mode on a PC browser. But that only worked because Apple basically strongarmed them into providing mp4 files, instead of Flash.
There are plenty of projects like this -- a corporation owns all the copyrights, so they can dual-license under GPL and something else. Even projects like Gentoo do this with "foundations", not for a profit, but so they can switch licenses if they have to. This is generally considered preferable to leaving everything GPLv2 only (like Linux), making it impractical to switch to anything else, as you'd need consent from every contributor. It's also generally considered preferable to leaving it GPLv2 or later, which means the FSF can create a new license, and people can then relicense your code under the new license -- it basically means instead of the project controlling the license, the FSF does.
The problem is when you want to ensure that your own contribution will always be used exclusively for open stuff. So, some contributor insists on only GPL, which means there's going to have to be a fork. No way around it.
Since any copying is stealing, you're not even allowed to buy one copy for every device you want to listen on, because you'd necessarily have to copy it from your computer to the device -- perhaps from a CD to your computer to a device.
Yes, according to this bitch, iPods are illegal, unless filled entirely with free/open music -- if she even knows such things exist.
Maybe not.
Assuming the people receiving these will have a computer anyway, better to keep the old one out of the landfill a bit longer. The power isn't much, compared to how much hardware is going into there. And you can get power for free (of environmental impact), sort of -- solar, wind, etc -- whereas you cannot get hardware for free.
Assuming the people receiving these would not have had a computer, that's a sociological win, but maybe an environmental lose. Generally, I prefer the sociological win, though it's hard to have a general policy -- I don't think we should club baby seals for just about any reason, but I do think everyone should have access to a computer and the Internet.
Based on vague rumor, memory, etc, I get the feeling that Google is doing something like this: Keep old hardware running as long as you can, it's just taking up space. When you need to expand the Google Grid, either get more space/power, or throw out the oldest hardware and replace it with brand new hardware. Also, probably tend to replace old, broken hardware with new, working hardware. I'm basically assuming that their grid is capable of being a heterogeneous environment.
Would it be more power-efficient to throw em away? Maybe, but they have an abundance of power -- I hear they are planning to build solar roofs over their parking lots, so that people with hybrid/electric cars can plug them in. Any extra power from that could just feed straight into the grid.
(All pure speculation -- I don't work at Google, and I have no more resources than the average Slashdotter to find out what goes on there.)
Indeed. Nothing about the system I proposed requires more duplication than we have, except for people wishing to run a different filesystem as root.
That's a fair point, but then...
Are you saying that what people want should dictate these decisions? Because if so, it seems plenty of people want the pluggable scheduler.
In that case, they get to run a patched kernel, and maybe not get updates, until they can either find a bootcd with a tool for migrating their data in-place (difficult to write for any filesystem), or they can back all their data up and restore it.
I seem to remember that Minix was, at one time, supported by the kernel. And I believe it's been removed, so anyone who was still using the original Minix or ext has to upgrade to ext2. And I believe ext2 is format-incompatible, meaning they had to back up and restore, though I could be wrong about that. I'm fairly sure ext4 will be incompatible, though.
Understand, too, that I'm playing devil's advocate here. I'm perfectly happy with pluggable filesystems, although I'm not particularly happy that so much of the filesystem is in the kernel, or that context switches are slow enough that it makes sense for them to be there. I'm just using it as a basis for explaining why I think pluggable schedulers might be a good idea.
Although there was another reply, kind of buried by now, maybe, pointing out that CFQ is very tunable and supports somewhat more limited plugins of its own. That would suggest it's more like replacing the Linux VFS with Reiser4 (and implementing existing filesystems as Reiser4 storage plugins), although I wouldn't recommend that either now, as unstable as Reiser (filesystem and person) can be.
Yeah. Sounds like ALSA/OSS.
In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.
Moreover, this is already true of every filesystem that I know of, to some extent. Remember that the userspace implementation need not provide everything the kernel implementation does -- even simple APIs to copy whole files in/out of the FS might be sufficient for most workloads.
But just how do you think mkfs.ext3 works? How about fsck.ext3? Or the various debugfs, dump, etc...
More likely, they'd develop it as a replacement. They'd use UserMode Linux, and they'd probably start with the ext3 code, so ext4 need never be in a state such that it can't be used as a root FS, even if only for a disk image.
More likely, ReiserFS would only be implemented in userspace. It's irrelevant -- using filesystems other than ext3 (or ext4) for your root filesystem is just wanking with settings, remember? You only need ReiserFS if some poor, uneducated soul happened to format their system with Reiser, then you have to use the userspace driver to back it up.
I imagine there are actually filesystems that have already moved to this level of support -- where the userspace utilities are really the only way of getting at the stuff, as all kernel support has been dropped.
Fortunately, there's still FUSE, but that's a big performance hit, and it does tend to invalidate your case against pluggable schedulers.
Free, you pirate it from a friend.
Or you get Gimp, or Krita, or Paint.NET... All more than enough for what we're describing.
Joe user won't be using Garage Band, and if he was, Linux has Ardour. What else about what you described is better?
True. However, the latter is neither illegal nor actively prevented by either company, to my knowledge.
Consider something that is pluggable, then -- the radio. You don't take a radio out of one car, put it into the other, and have it refuse to work because it's not in a Ford. What's more, this would be considered unacceptable behavior.
So why does Apple spend so much effort and expense trying to lock their stuff down?
Except it also means Joe User now has to wonder, sometimes, why his new Macbook runs some apps slower than his old Powerbook did.
And it has to be transparent for developers, not just users. UT2004 came with the Linux installers on the same disc as the Windows installers, so you don't have to think about it -- if you bought UT2k4, you have the version you need for either. (Not sure about the OS X version, but I've known OS9 and older Mac programs to be bundled on the same disc as the Windows version.)
However, I guarantee the actual work of porting was not easy. Thus, you don't see many discs like this, and users are surprised when stuff "just works". Xcode makes it easy to compile a "Universal Binary", but you still need to actually go buy each kind of machine to be sure, otherwise you're going to hit obscure bugs -- if you haven't already hit obscure compiler bugs.
I want you to go back and re-read that, but replace "byte code" with "compiled".
Speed was a big one in the past, but it's not because processors are so fast now. I'd still like to let my fans spin down and stop burning my lap now and then.
But consider: We used to think compiled languages were slower than assembly. Turns out, the gains from intelligent, optimizing compilers are huge -- big enough that only in very performance-critical apps do you even consider assembly, and there, you do it in very, very small amounts, and test thoroughly. You do this because the compiler is smart enough that you, as a human, could easily do a worse job translating than the compiler did.
Google for "A Plan for Spam" for an example of why, sometimes, we really ought to just let the computer do the work.
Bytecode engines can do runtime optimizations. A simple example: A bytecode engine can analyze a given function, or instruction, or whatever unit you want to use, and compile several different variants of it, each of which works better under different circumstances. Then, by actually looking at the real workload being used right now, it can figure out which one is better, right now. If the workload changes, it might use a different
Unless Dell (or Ubuntu) has done something different, to my knowledge, you still have to do this:
I know it's not hard. It's certainly easier to keep them updated. Hell, steps 6-7 might no longer be necessary.
But it's a far cry from "one click", especially for someone who just bought their first Dell with Ubuntu. And having to use the VGA drivers can slow the machine down a LOT, which means people walk away from the experience with either the opinion that Linux is only for those who know what they're doing (since you have to type confusing stuff into a terminal), or that Linux sucks, performance is awful, etc etc.
Unless I'm wrong, and Dell really has made it "one-click" and BLATANTLY obvious (along the lines of asking the user a question right after they agree to the EULA), I would almost rather they not sell Linux. At least if someone's installing it themself, they expect problems, but if they actually order a whole computer, they not only expect everything to be working, but they also will have invested money, and will have a very real sense of being ripped off.
That'd be another no, and no.
Maybe it's just me, but I had to explicitly add a "resume=/dev/sda5" (or whatever) argument to my kernel commandline. And while my wireless worked out of the box, I have a friend who has the one broadcom card that isn't even supported with the native (bring-your-own-firmware) drivers, so I'm going to have to walk him through ndiswrapper.
On my own laptop, sound doesn't work out of the box either -- I'm probably going to have to get the CVS (or whatever it is these days) of the ALSA drivers to make it work, maybe.
I'll be the first to admit that the codec situation is bad, but no worse than the drivers. After all, mp3 works out of the box, right?
<sarcasm>They only think they need them. Really, they're just wanking around with their settings.</sacrams>
Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network, ISO/UDF, and FAT/NTFS, can be done in userspace -- see the various userspace VFS projects -- they don't have to be fast anyway, since they're generally removable media, or stuff rarely accessed. Anyone booting from the network is probably running a custom kernel anyway.
These are all arguments I've heard people use against pluggable schedulers, which don't make sense here. After all, you can't have two root filesystems at the same time...
And some systems don't need pre-emptive scheduling. And some of them could certainly do better with a round-robin scheduler, so that more time is spent crunching and less is spent deciding what to do.
The point is that the main kernel maintainers are deciding what's important and what's not. I don't know enough to understand whether it's seriously problematic to implement a pluggable scheduling system, but this does not get to be dismissed as "not important", and certainly not as "people just wanking with their settings". Multiple schedulers are necessary, in some form, even if they have to be in separate kernel forks.
True enough, or at least, they don't use a kernel compiled with vanilla options.
The whole point of wanting a pluggable scheduler is to let the end-user answer that "for what" question, instead of having Linus answer it for you, or have to use a fork.
I don't argue that it has to be pluggable at runtime, and though I haven't been following this, I suspect that "at runtime" is what would slow down the architecture. Because if it's just another menuconfig option, that slows down development, not execution.
If it had to be hot-pluggable -- as I believe some of these are -- then yes.
But just run "make menuconfig" and take a look at the insane number of options you have for compiling a Linux kernel. It seems to me that slapping some #ifdef statements around some code isn't going to make it perform any worse.
It might, however, be harder to maintain.
In security? Yes it does!
I mean, yes, we'll often choose the more secure model over the better-performing one, but not always. Consider the performance implications of, for example, trying to predict every possible state a program could be in, so you could determine whether or not to run the program -- programs which might possibly do things they aren't allowed to never get run in the first place.
Obviously, we don't do that. We do the analysis at runtime -- when a program attempts to do something it's not allowed to, we block it then, we don't try to predict it happening.
Except from what I understand, SELinux and ACLs are a superset of traditional Unix security, and could, in fact, completely replace it (and emulate it). So why not make SELinux the only security architecture?
Hasn't the work already been done, though?
I understand that it needs to be maintainable, but I would think a flexible architecture would be MORE maintainable, not less.
(I admit that I don't have enough experience to make such a statement, at least about Linux and C.)
Specifically, I remember reading about a case in which two contributors kept sending in patches that deliberately broke each others' code.
Linus simply stopped accepting patches from either of them until they sorted out their differences.
He could have chosen sides, but he didn't.
Yay for creative grammar... I apologize to anyone else who caught that. Preview is not my friend today :(