It might be advanced and very fast - but it is NOT mainline nor accepted.
Which is also not the issue.
Also check XFS people: they do not scream laud albeit their file system is alos unsupported by Gentoo though it is in mainline kernel.
Wasn't asking for support or endorsement, merely accurate representation. I'd be equally annoyed, for instance, if they claimed Vista was in Beta. I don't like Vista, and I think it's still Beta quality, but it's been released for awhile now.
IOW, the response you have received from Gentoo was more like "we have our hands full with mainline file systems to bother with something external."
Which seems both blatantly false (see below) and irrelevant. It was a documentation issue, not a support issue, and it was about three words.
For instance: They have sys-fs/reiser4progs-1.0.5 in the Portage tree. It's not only there, but it's unmasked. Sadly, they may be right about the fsck being more stable than the FS itself...
My point is, what I was complaining about would be roughly equivalent to them calling it "sys-fs/reiser4progs-1.0.5_beta", and using the same source. There's a difference between saying you don't like something and outright lying about it.
I'm finding it hard to locate the actual chunk of documentation I had a problem with. I can certainly point to some unfriendly ones -- this is just stupid, there's nothing to stop you from patching your own kernel and running it anyway, and I have two Gentoo systems and one Ubuntu system running on Reiser4. The correct thing to put there would be "We don't support it."
However, I can't find either my bug report or the original page I didn't like. It was some sort of very small comparison matrix between various filesystems. So for now, there's nothing wrong; however, it was NOT simply an issue of "We support this" or "We don't support this". If it was, it wouldn't have bothered me at all.
Instead, it was more like, "We don't support this, it's unstable and alpha..." which was actually a factual mistake. Not a political mistake, not a wrong choice, but a simple, factual mistake. And no matter how many times I re-opened the bug, I got exactly the response I'm getting from you -- missing the point entirely.
Unless there's a downside, why wouldn't you? And I can definitely think of one reason:
Suppose someone comes to me with a "dead" notebook hard drive. If the notebook won't boot enough for me to run a livecd, or if it doesn't even have a cdrom drive, I could still open it up, grab the SATA drive, and plug it into my desktop to test it there. Much more convenient with things like the Powerbook's FireWire target mode, but you get this one for free.
The problem I have is that there isn't consistent naming for the Perl packages that are there. 90% of what I need exists in the official repositories, if I can figure out what bundle contains which CPAN packages.
And the link you provided is helpful, and I'll keep it in mind. Still, it's quite a lot of steps and a bit of manual work, compared to:
g-cpan -i Foo::Module
And g-cpan is smart enough to know which ones already exist in the Portage tree. For those that don't, it will generate packages for those packages and all their dependencies until it runs into stuff that's already in the tree.
From what I can tell, the reason their response is slow is because they're pulling in results from other search engines. In fact, how can they compete with Google when they depend so thoroughly on it?
Worst case, you write a software utility to duplicate the BIOS support. While on the livecd, you have normal access to the disk (via dm-crypt, say), no matter what standard they're in. If you have to set it up to be accessed by OSes which can't or won't implement that crypto, you can convert it to the local scheme on the fly, even in place -- risky, but doable, as pretty much all our ciphers now are 1:1 as far as size goes. Read block, decrypt, encrypt to the new scheme, write block back out over original, repeat till the disk is converted.
But really, why the hell would they? AES is the standard, unless they're going to use DES. The others are not any kind of standard except with respect to themselves, which is kind of like saying my comment is a standard comment because it says so. And Blowfish is fast, but not significantly faster to be actually noticeable relative to the speed of the actual disk, or the amount of CPU comes in a standard box these days. Only reason they would do that is to be buzzword compliant and piss people off when trying to move between motherboards.
The main target for these things are going to be laptops where you want to use as few CPU cycles as possible.
In which case, wouldn't it be nice to be able to use the same hardware crypto for, say, your corporate VPN?
As soon as you mention putting two of these in a system you're not talking about a laptop any more.
There are actually laptops with two-disk RAID in them.
As for using a general purpose 'crypto card'. Thats like saying to use general purpose RAM instead of a buffer on the hard drive.
Well, general purpose RAM does exist, doesn't it? The general purpose crypto card doesn't, in this case -- at least, not for a laptop.
I'm sure these chips being right on the same logic board as the hard drive perform much better than a general purpose crypto card would
Encryption does not change the amount of data that is there. If you send 10 megs to the disk, it's still 10 megs, encrypted or not. The performance boost is from not using CPU cycles -- it really has nothing to do with it being closer to the disk.
I suppose it would be using less of whatever bus is concerned (RAM speed might be an issue, too), so I wonder if you could do some DMA tricks to make it work. Does DMA only allow hardware to directly access RAM? Or can it send stuff between two separate pieces of hardware -- like, say, straight from disk to network?
Well, PATA is right out for me. SATA has hotplugging and much nicer connectors. As for 3G vs 1, I'll leave that to others to answer.
Gee, how long did it take us to get revdep-rebuild
on
Is Gentoo in crisis?
·
· Score: 1
And it's still dog slow and potentially dangerous. I'm fairly sure apt-get had its autoremove feature long before Gentoo had any kind of reverse deps -- and, indeed, aptitude will do this for you, in far less time than it takes to even get Gentoo to do an "emerge -uaDN world", much less a depclean.
USE flags? Well, it doesn't matter so much -- disk space is cheap, bandwidth is cheap, so it takes far less time to download and install the extra libs than it does to compile the app without those libs.
But even if you reject that, it's been my experience that Ubuntu is able to slice packages up finely enough that you can get that functionality anyway. In Gentoo, flac support for xmms is, I believe, an xmms flag of the flac ebuild. In Ubuntu, it's simply a separate, optional-but-recommended package that you can choose not to install -- and you don't have to recompile a package to remove functionality, you just remove one of these little packages.
There really are very few cases where USE flags actually matter, and in those cases (SMP vs not, for example), you'll get separate ebuilds.
That's actually one of my bigger gripes about Gentoo -- in fact, I submitted a bug about documentation, which people refused to fix or understand.
I can't find it now, and I suspect the bug report is gone.
Basically, their installation instructions -- or some similar documentation -- mentioned Reiser4 and warned that it was unstable, beta stuff, or something like that. I pointed out that it may be unstable (and they could say that), but it was obviously, factually wrong to claim it was beta, as the code has been released as a final version. This went back and forth for awhile, with the guy handling the bug report continually insisting that he would not accept it as stable, and refusing to budge at all.
So, maybe it's good documentation, I don't really know anymore. But it's kind of ruined when you get that kind of ego in the way -- even when it's just the documentation. Who knows what other inaccuracies there are in there, simply because a developer doesn't want to even acknowledge an issue?
If it were BIOS crypto, what happens when Phoenix uses AES and AMI uses Blowfish?
That's what standards are for, and AES is the standard. Or they could do what HD-DVD/Blu-Ray does and pick a few, and declare that those are possible standards.
Most things like this can be done in software or in hardware. Which is only part of the point.
Let me put it this way: How would you feel if you didn't buy a "video card", but rather a "Half-Life 2 card"? Video cards are as generic as they reasonably can be. This is hardware to help with encryption, and I don't see anything about it that would tie it to the hard drive other than user convenience. If you really need hardware-accelerated crypto -- and you probably don't; modern CPUs can probably do the crypto faster than modern hard drives can read/write the data -- then shouldn't you have a dedicated crypto card or chip which works for accelerating any crypto the OS wants it to?
And why should you pay for the same hardware twice? That is, say I get two of these hard drives, and put them both in the same computer -- doesn't it make more sense to just have one crypto chip shared between them? I certainly don't have to buy two video cards to get 3D acceleration on dual monitors, although I can buy two of them and get twice the performance out of one monitor. This should be the same, unless it's somehow much cheaper this way (and I'm guessing it's not) -- if I really need more crypto speed to handle a 15 terabyte array hooked to a couple of gigabit pipes, I should just buy more/better crypto cards.
I'm also pretty sure this kind of thing exists already, somewhere. Not on consumer hardware, though.
Only advantage I see to doing it this way is that it's no longer possible for someone to steal the drive, put a rootkit on your kernel (in your boot partition), and give it back to you without you noticing. But if they can do that, they can probably stick a hardware keylogger on your keyboard anyway.
It just makes it nice for the consumer to be able to plug the hard drive into a machine and have encryption working out of the box with no setup.
Which, as I said, can be accomplished (as well as it possibly could be) without special hardware. Worst case, you do some BIOS hack. But it's not going to work with no setup; the user is going to have to supply an encryption key.
Reason #1 is sheer transparency. I can do an ebuild in my sleep, and it certainly makes it a lot easier to dig around when something's wrong. Whether it's because of the binary nature, or because I simply don't know how to use it, I'm just not as proficient with hacking apt stuff.
Reason #2 is g-cpan, and things like it. Ubuntu has to manually go and re-package CPAN libs, Gentoo can automagically generate them for things which don't require special care. In general, Gentoo's philosophy of a package being an ebuild being a shell script makes it a lot easier to use other packaging systems. Did the bastards only provide an RPM? Have your ebuild download the original RPM, unpack it using tools like rpm2targz or even rpm itself, and install it as a Gentoo package. Again, this may be my own lack of understanding, but it seems like this kind of thing is tricker -- both legally and technologically -- with a system like apt.
Reason #3 is laziness. It's already on my desktop and server, and so far, it's been one steady problem after another, but never something that, by itself, takes longer than switching to Ubuntu.
However, I do set up all my new systems as Ubuntu or another debian-derived distro. The main points of Gentoo beyond that are arch-specific compiletime optimizations and USE flags. The machines I really want to perform well are amd64, and that's at the point where you lose pretty much nothing by compiling for generic x86_64 rather than athlon64 -- in fact, I think it's exactly equivalent with the current gcc. For awhile, I was using -O3, then I used -Os because I thought it made stuff faster, then I realized it wasn't making a noticeable difference, and even if it was, hardware is optimized for Windows and bloaty crap, so CPU caches are getting bigger all the time. -O2 seemed the sane compromise -- but most things compile with that anyway, and most of the other optimizations I wanted to try both break things when applied globally and are enabled by things for which they would make a difference anyway (like mplayer).
Compiling your own kernel probably used to give a significant performance boost, and possibly still does if you know what you're doing, but it's just a huge amount of time to spend running through the config dialogs. But even if I wanted to, Ubuntu makes it easier anyway -- make-kpkg is nice.
As for USE flags, they still can control useful stuff -- for instance, whether or not something compiles with an optional GUI. However, unless you really need to save every last bit of disk space, this means nothing. And even if you do, binary distros are able to slice things up a lot finer than source ones have been able to do in the past -- it used to be that installing one little gtk app required compiling a whole X server and all the X libs, whereas on Ubuntu, it installs maybe a meg or two worth of the base X libs (plus gtk, which isn't big either). In fact, one of the biggest uses of USE flags lately has been to deliberately disable functionality you won't be using, just to make stuff compile faster -- for example, if you specify your soundcard, alsa-driver won't compile every single soundcard ever made.
But that's to make livable a situation where the granularity of your package system is limited by what you can compile on its own, and typically, you'll end up downloading the full sources even if you only need to compile 10%, and only actually need 10% of the result of that. Which makes their old "Larry the Cow" slogan sadly obsolete -- with Gentoo, you end up compiling and installing much more than you need, in order to, say, not compile gtk support unless you need it -- and then have gtk compile and install the first time you actually do get a gtk-only app.
And Ubuntu does a better job of this, anyway. Plugins are a great example -- on Gentoo, you might compile xmms with flac support, or flac with xmms support. On Ubuntu, you just install xmms-flac or something -- one package that's just the flac plugin for xmms. I don't use xmms anymore, but there you go -- if
I guess I still don't get it -- tell me again why doing this in the HDD circuitry is useful?
I mean, we still do software RAID, and find it pretty useful -- and it's at the point where there's plenty of "fakeraid" out there to deal with Windows' lack of good (cheap) RAID tools. So, why not just implement something similar -- BIOS crypto? That would make it easy enough, without actually having to put more circuitry on the drive.
For that matter, it seems to me like it would make much more sense to have a generic hardware crypto device, so you can use it for other things -- ipsec being another obvious example.
Well, depending on the distro, Dell could simply transfer them to, say, someone at Canonical.
But really, full support for Linux should be somewhat easier than full support for Windows in at least one respect: They can fix it themselves. In fact, if they setup their own repository, they can not only fix it, but automatically distribute it to Grandma (to the point where Grandma just has to click "install updates" in one place). And they won't get anywhere near the same amount of flak for this as they would for doing the same on Windows, because every Linux geek who cares about this is going to know how to edit sources.list to point to the official Ubuntu repository, or even a Debian repository, if they don't like what Dell does with it.
Yakuake, I think it's called, maybe the third one down.
This looks decidedly cool. All those people who are used to hitting tilde to get under the hood of their FPS and cheat, or just tweak stuff (admin_slap even)... Well, now they understand. Commandline is cheats for Linux!
I just recently migrated a whole office over to the new DST settings. Basically followed the instructions on the Microsoft website, went with my brother and applied a registry hack to all the machines. In fact, if the domain had been set up properly, we could've had it automatically apply the patch to any Win2K box on the network as soon as it boots.
I mean, never mind that the XP boxes and my own Linux systems have been wholly unaffected -- just grab the latest patches and you're good.
But why is this hard for people? Worst case, you can manually go edit the timezone! Microsoft provides a tool called "tzedit", which allows you to set when DST starts, when it ends, and what the delta is.
Camera is really everything with next generation. It doesn't matter how good your graphics are, if you can't see them.
Haven't played Gears, but one hint for prospective game developers: Either make your camera placement absolutely fucking flawless, or let us rotate the camera on our own. Note that letting us rotate the camera is no excuse for having the camera suck so much that we have to do it all the time.
talk about Red Hat or SuSE or whatever, not Linux in general.
I generally talk about Ubuntu when I want to talk about a whole distro; for instance, Ubuntu vs XP, or Ubuntu vs Vista. However, the fact that there are choices is a good thing. I've got a borrowed HP Jornada 720, and it runs a Linux distro designed specifically for it.
And let's be honest: Other OSes can be more diverse in their implementations than Linux distros. Take Windows Mobile or Windows CE vs any desktop Windows. At least with my Jornada, I can simply recompile desktop Linux software for the ARM processor and have it work -- Firefox being one example. Windows Mobile is more than a recompile, it's a port -- possibly more of a port than between different Unixes (Linux, Solaris, OS X), let alone different Linux distros.
Is Linux Secure? Despite what I just said, talking about general Linux is convenient, so I'll now do it myself....
At this point, TFA says something about how there are reports supporting both sides of the argument -- neglecting, of course, to look at how independent these reports really are.
I mean, you can say that it's a knee-jerk Slashdotter reaction that every report which favors Microsoft must somehow have been paid for by Microsoft. But that's because this is largely true. Whether or not Windows is cheaper, more secure, whatever, it's hard to find a report about Windows not from someone either directly funded by Microsoft, or with a vested interest in keeping people on Windows -- Symantec, for instance. Don't need antivirus on Linux, so if people discovered that Linux was more secure, Symantec might be out of a business model.
He mentions PJ of Groklaw "covering something up"... woman values her privacy! There must be something sinister here! It seems the focus of his rant is that anonymous people contribute patches -- fine, but trusted and respected people do verify each patch before it's applied. So yeah, Linus could 0wn us all, but I think he's proven his trustworthiness by now -- and Andrew Morton or someone else would catch him anyway.
Ultimately, his conclusion is it doesn't matter which OS is more secure, you need to audit your physical security. WTF?
Yeah, I lock my home at night. Now let's go back to how Microsoft can take months to fix critical security flaws which it won't even admit are "critical", while Linux tends to release a patch the next day.
Community efforts never work. Just look at the debate over the GPL3, which by the way is "anti-business" and a threat to intellectual property everywhere.
And here he goes again, generalizing just enough to make his point true. For instance: "Right now they can't even agree if they need a new one, and the two sides have, as they seem more than willing to do, degraded into name-calling." You know what? The FSF does agree with itself that they need a new license. Linus is part of a different community. That's kind of like saying the US government doesn't work because Osama Bin Laden disagrees with people inside it -- implying that Osama is part of the government? WTF?
Let's see... people aren't paid for it, yadda yadda... Not even going to argue with this one, because it's plainly retarded. There is such a thing as volunteer work. Just because it kicked your ass at SCO doesn't invalidate it for the rest of us.
And no, not everyone using Linux will be effected -- in fact, the Linux kernel itself is not affected, and probably never will be. Or would you like to start talking about specific distros now?
Oh, and it's a threat to intellectual property... how? If you don't like it, don't license under it. And frankly, I'm not surprised that the FSF doesn't listen to you.
4. Is Linux Pro-Developer, or Pro-You?... I'm not smart enough to understand open source business models, so I'll imply you can't make money giving away software, then throw out some FUD that Linux equals
Well, securing a desktop that only has to run Firefox -- not even a full window manager -- seems a lot easier than securing a desktop that has to run a bunch of apps.
Also puts more responsibility on you -- for example, you now have to run the fileserver, or sacrifice the ability of an employee to sit down at any terminal.
Personally, I'd do it all in-house, but this is a way of outsourcing to Google and only having to maintain a very simple disk image and a bunch of extremely lightweight desktop machines. Bonus is if you change your mind and have to migrate to something else, or even back to Windows, all your stuff is already there, you don't have to convert a bunch of opendocument stuff to something else. It's not hard to see the attraction.
Not if your hard drive is switched off (remember this is laptops we are talking about). It takes quite a while and a lot of power for a hard drive to spin up. You can get data from a flash chip within micro secs of switching it on.
Point here is that if you're replacing the flash with RAM, instead of with disk, then it's already on anyway. If anything, it's faster than the Flash drive -- Flash has better seek time and startup time, but worse throughput.
You do realize the power button is next to the keyboard, inside the clamshell, right?
I guess I could try turning it on and quickly closing the lid, or actually doing wake-on-lan (set top box)... Probably easier just to cover the magnet.
Slashdot Mirror
Which is also not the issue.
Wasn't asking for support or endorsement, merely accurate representation. I'd be equally annoyed, for instance, if they claimed Vista was in Beta. I don't like Vista, and I think it's still Beta quality, but it's been released for awhile now.
Which seems both blatantly false (see below) and irrelevant. It was a documentation issue, not a support issue, and it was about three words.
For instance: They have sys-fs/reiser4progs-1.0.5 in the Portage tree. It's not only there, but it's unmasked. Sadly, they may be right about the fsck being more stable than the FS itself...
My point is, what I was complaining about would be roughly equivalent to them calling it "sys-fs/reiser4progs-1.0.5_beta", and using the same source. There's a difference between saying you don't like something and outright lying about it.
I'm finding it hard to locate the actual chunk of documentation I had a problem with. I can certainly point to some unfriendly ones -- this is just stupid, there's nothing to stop you from patching your own kernel and running it anyway, and I have two Gentoo systems and one Ubuntu system running on Reiser4. The correct thing to put there would be "We don't support it."
However, I can't find either my bug report or the original page I didn't like. It was some sort of very small comparison matrix between various filesystems. So for now, there's nothing wrong; however, it was NOT simply an issue of "We support this" or "We don't support this". If it was, it wouldn't have bothered me at all.
Instead, it was more like, "We don't support this, it's unstable and alpha..." which was actually a factual mistake. Not a political mistake, not a wrong choice, but a simple, factual mistake. And no matter how many times I re-opened the bug, I got exactly the response I'm getting from you -- missing the point entirely.
Unless there's a downside, why wouldn't you? And I can definitely think of one reason:
Suppose someone comes to me with a "dead" notebook hard drive. If the notebook won't boot enough for me to run a livecd, or if it doesn't even have a cdrom drive, I could still open it up, grab the SATA drive, and plug it into my desktop to test it there. Much more convenient with things like the Powerbook's FireWire target mode, but you get this one for free.
The problem I have is that there isn't consistent naming for the Perl packages that are there. 90% of what I need exists in the official repositories, if I can figure out what bundle contains which CPAN packages.
And the link you provided is helpful, and I'll keep it in mind. Still, it's quite a lot of steps and a bit of manual work, compared to:
g-cpan -i Foo::Module
And g-cpan is smart enough to know which ones already exist in the Portage tree. For those that don't, it will generate packages for those packages and all their dependencies until it runs into stuff that's already in the tree.
From what I can tell, the reason their response is slow is because they're pulling in results from other search engines. In fact, how can they compete with Google when they depend so thoroughly on it?
If we're talking about something you'd want to ride in the desert, a horse is a camel designed by a PR department. Or by Steve Jobs.
Worst case, you write a software utility to duplicate the BIOS support. While on the livecd, you have normal access to the disk (via dm-crypt, say), no matter what standard they're in. If you have to set it up to be accessed by OSes which can't or won't implement that crypto, you can convert it to the local scheme on the fly, even in place -- risky, but doable, as pretty much all our ciphers now are 1:1 as far as size goes. Read block, decrypt, encrypt to the new scheme, write block back out over original, repeat till the disk is converted.
But really, why the hell would they? AES is the standard, unless they're going to use DES. The others are not any kind of standard except with respect to themselves, which is kind of like saying my comment is a standard comment because it says so. And Blowfish is fast, but not significantly faster to be actually noticeable relative to the speed of the actual disk, or the amount of CPU comes in a standard box these days. Only reason they would do that is to be buzzword compliant and piss people off when trying to move between motherboards.
In which case, wouldn't it be nice to be able to use the same hardware crypto for, say, your corporate VPN?
There are actually laptops with two-disk RAID in them.
Well, general purpose RAM does exist, doesn't it? The general purpose crypto card doesn't, in this case -- at least, not for a laptop.
Encryption does not change the amount of data that is there. If you send 10 megs to the disk, it's still 10 megs, encrypted or not. The performance boost is from not using CPU cycles -- it really has nothing to do with it being closer to the disk.
I suppose it would be using less of whatever bus is concerned (RAM speed might be an issue, too), so I wonder if you could do some DMA tricks to make it work. Does DMA only allow hardware to directly access RAM? Or can it send stuff between two separate pieces of hardware -- like, say, straight from disk to network?
Well, PATA is right out for me. SATA has hotplugging and much nicer connectors. As for 3G vs 1, I'll leave that to others to answer.
And it's still dog slow and potentially dangerous. I'm fairly sure apt-get had its autoremove feature long before Gentoo had any kind of reverse deps -- and, indeed, aptitude will do this for you, in far less time than it takes to even get Gentoo to do an "emerge -uaDN world", much less a depclean.
USE flags? Well, it doesn't matter so much -- disk space is cheap, bandwidth is cheap, so it takes far less time to download and install the extra libs than it does to compile the app without those libs.
But even if you reject that, it's been my experience that Ubuntu is able to slice packages up finely enough that you can get that functionality anyway. In Gentoo, flac support for xmms is, I believe, an xmms flag of the flac ebuild. In Ubuntu, it's simply a separate, optional-but-recommended package that you can choose not to install -- and you don't have to recompile a package to remove functionality, you just remove one of these little packages.
There really are very few cases where USE flags actually matter, and in those cases (SMP vs not, for example), you'll get separate ebuilds.
That's actually one of my bigger gripes about Gentoo -- in fact, I submitted a bug about documentation, which people refused to fix or understand.
I can't find it now, and I suspect the bug report is gone.
Basically, their installation instructions -- or some similar documentation -- mentioned Reiser4 and warned that it was unstable, beta stuff, or something like that. I pointed out that it may be unstable (and they could say that), but it was obviously, factually wrong to claim it was beta, as the code has been released as a final version. This went back and forth for awhile, with the guy handling the bug report continually insisting that he would not accept it as stable, and refusing to budge at all.
So, maybe it's good documentation, I don't really know anymore. But it's kind of ruined when you get that kind of ego in the way -- even when it's just the documentation. Who knows what other inaccuracies there are in there, simply because a developer doesn't want to even acknowledge an issue?
That's what standards are for, and AES is the standard. Or they could do what HD-DVD/Blu-Ray does and pick a few, and declare that those are possible standards.
Most things like this can be done in software or in hardware. Which is only part of the point.
Let me put it this way: How would you feel if you didn't buy a "video card", but rather a "Half-Life 2 card"? Video cards are as generic as they reasonably can be. This is hardware to help with encryption, and I don't see anything about it that would tie it to the hard drive other than user convenience. If you really need hardware-accelerated crypto -- and you probably don't; modern CPUs can probably do the crypto faster than modern hard drives can read/write the data -- then shouldn't you have a dedicated crypto card or chip which works for accelerating any crypto the OS wants it to?
And why should you pay for the same hardware twice? That is, say I get two of these hard drives, and put them both in the same computer -- doesn't it make more sense to just have one crypto chip shared between them? I certainly don't have to buy two video cards to get 3D acceleration on dual monitors, although I can buy two of them and get twice the performance out of one monitor. This should be the same, unless it's somehow much cheaper this way (and I'm guessing it's not) -- if I really need more crypto speed to handle a 15 terabyte array hooked to a couple of gigabit pipes, I should just buy more/better crypto cards.
I'm also pretty sure this kind of thing exists already, somewhere. Not on consumer hardware, though.
Only advantage I see to doing it this way is that it's no longer possible for someone to steal the drive, put a rootkit on your kernel (in your boot partition), and give it back to you without you noticing. But if they can do that, they can probably stick a hardware keylogger on your keyboard anyway.
Which, as I said, can be accomplished (as well as it possibly could be) without special hardware. Worst case, you do some BIOS hack. But it's not going to work with no setup; the user is going to have to supply an encryption key.
Reason #1 is sheer transparency. I can do an ebuild in my sleep, and it certainly makes it a lot easier to dig around when something's wrong. Whether it's because of the binary nature, or because I simply don't know how to use it, I'm just not as proficient with hacking apt stuff.
Reason #2 is g-cpan, and things like it. Ubuntu has to manually go and re-package CPAN libs, Gentoo can automagically generate them for things which don't require special care. In general, Gentoo's philosophy of a package being an ebuild being a shell script makes it a lot easier to use other packaging systems. Did the bastards only provide an RPM? Have your ebuild download the original RPM, unpack it using tools like rpm2targz or even rpm itself, and install it as a Gentoo package. Again, this may be my own lack of understanding, but it seems like this kind of thing is tricker -- both legally and technologically -- with a system like apt.
Reason #3 is laziness. It's already on my desktop and server, and so far, it's been one steady problem after another, but never something that, by itself, takes longer than switching to Ubuntu.
However, I do set up all my new systems as Ubuntu or another debian-derived distro. The main points of Gentoo beyond that are arch-specific compiletime optimizations and USE flags. The machines I really want to perform well are amd64, and that's at the point where you lose pretty much nothing by compiling for generic x86_64 rather than athlon64 -- in fact, I think it's exactly equivalent with the current gcc. For awhile, I was using -O3, then I used -Os because I thought it made stuff faster, then I realized it wasn't making a noticeable difference, and even if it was, hardware is optimized for Windows and bloaty crap, so CPU caches are getting bigger all the time. -O2 seemed the sane compromise -- but most things compile with that anyway, and most of the other optimizations I wanted to try both break things when applied globally and are enabled by things for which they would make a difference anyway (like mplayer).
Compiling your own kernel probably used to give a significant performance boost, and possibly still does if you know what you're doing, but it's just a huge amount of time to spend running through the config dialogs. But even if I wanted to, Ubuntu makes it easier anyway -- make-kpkg is nice.
As for USE flags, they still can control useful stuff -- for instance, whether or not something compiles with an optional GUI. However, unless you really need to save every last bit of disk space, this means nothing. And even if you do, binary distros are able to slice things up a lot finer than source ones have been able to do in the past -- it used to be that installing one little gtk app required compiling a whole X server and all the X libs, whereas on Ubuntu, it installs maybe a meg or two worth of the base X libs (plus gtk, which isn't big either). In fact, one of the biggest uses of USE flags lately has been to deliberately disable functionality you won't be using, just to make stuff compile faster -- for example, if you specify your soundcard, alsa-driver won't compile every single soundcard ever made.
But that's to make livable a situation where the granularity of your package system is limited by what you can compile on its own, and typically, you'll end up downloading the full sources even if you only need to compile 10%, and only actually need 10% of the result of that. Which makes their old "Larry the Cow" slogan sadly obsolete -- with Gentoo, you end up compiling and installing much more than you need, in order to, say, not compile gtk support unless you need it -- and then have gtk compile and install the first time you actually do get a gtk-only app.
And Ubuntu does a better job of this, anyway. Plugins are a great example -- on Gentoo, you might compile xmms with flac support, or flac with xmms support. On Ubuntu, you just install xmms-flac or something -- one package that's just the flac plugin for xmms. I don't use xmms anymore, but there you go -- if
I guess I still don't get it -- tell me again why doing this in the HDD circuitry is useful?
I mean, we still do software RAID, and find it pretty useful -- and it's at the point where there's plenty of "fakeraid" out there to deal with Windows' lack of good (cheap) RAID tools. So, why not just implement something similar -- BIOS crypto? That would make it easy enough, without actually having to put more circuitry on the drive.
For that matter, it seems to me like it would make much more sense to have a generic hardware crypto device, so you can use it for other things -- ipsec being another obvious example.
Well, depending on the distro, Dell could simply transfer them to, say, someone at Canonical.
But really, full support for Linux should be somewhat easier than full support for Windows in at least one respect: They can fix it themselves. In fact, if they setup their own repository, they can not only fix it, but automatically distribute it to Grandma (to the point where Grandma just has to click "install updates" in one place). And they won't get anywhere near the same amount of flak for this as they would for doing the same on Windows, because every Linux geek who cares about this is going to know how to edit sources.list to point to the official Ubuntu repository, or even a Debian repository, if they don't like what Dell does with it.
Yakuake, I think it's called, maybe the third one down.
This looks decidedly cool. All those people who are used to hitting tilde to get under the hood of their FPS and cheat, or just tweak stuff (admin_slap even)... Well, now they understand. Commandline is cheats for Linux!
I just recently migrated a whole office over to the new DST settings. Basically followed the instructions on the Microsoft website, went with my brother and applied a registry hack to all the machines. In fact, if the domain had been set up properly, we could've had it automatically apply the patch to any Win2K box on the network as soon as it boots.
I mean, never mind that the XP boxes and my own Linux systems have been wholly unaffected -- just grab the latest patches and you're good.
But why is this hard for people? Worst case, you can manually go edit the timezone! Microsoft provides a tool called "tzedit", which allows you to set when DST starts, when it ends, and what the delta is.
Pure genius:
Haven't played Gears, but one hint for prospective game developers: Either make your camera placement absolutely fucking flawless, or let us rotate the camera on our own. Note that letting us rotate the camera is no excuse for having the camera suck so much that we have to do it all the time.
I really, really need to go play Gears.
I generally talk about Ubuntu when I want to talk about a whole distro; for instance, Ubuntu vs XP, or Ubuntu vs Vista. However, the fact that there are choices is a good thing. I've got a borrowed HP Jornada 720, and it runs a Linux distro designed specifically for it.
And let's be honest: Other OSes can be more diverse in their implementations than Linux distros. Take Windows Mobile or Windows CE vs any desktop Windows. At least with my Jornada, I can simply recompile desktop Linux software for the ARM processor and have it work -- Firefox being one example. Windows Mobile is more than a recompile, it's a port -- possibly more of a port than between different Unixes (Linux, Solaris, OS X), let alone different Linux distros.
At this point, TFA says something about how there are reports supporting both sides of the argument -- neglecting, of course, to look at how independent these reports really are.
I mean, you can say that it's a knee-jerk Slashdotter reaction that every report which favors Microsoft must somehow have been paid for by Microsoft. But that's because this is largely true. Whether or not Windows is cheaper, more secure, whatever, it's hard to find a report about Windows not from someone either directly funded by Microsoft, or with a vested interest in keeping people on Windows -- Symantec, for instance. Don't need antivirus on Linux, so if people discovered that Linux was more secure, Symantec might be out of a business model.
He mentions PJ of Groklaw "covering something up"... woman values her privacy! There must be something sinister here! It seems the focus of his rant is that anonymous people contribute patches -- fine, but trusted and respected people do verify each patch before it's applied. So yeah, Linus could 0wn us all, but I think he's proven his trustworthiness by now -- and Andrew Morton or someone else would catch him anyway.
Ultimately, his conclusion is it doesn't matter which OS is more secure, you need to audit your physical security. WTF?
Yeah, I lock my home at night. Now let's go back to how Microsoft can take months to fix critical security flaws which it won't even admit are "critical", while Linux tends to release a patch the next day.
And here he goes again, generalizing just enough to make his point true. For instance: "Right now they can't even agree if they need a new one, and the two sides have, as they seem more than willing to do, degraded into name-calling." You know what? The FSF does agree with itself that they need a new license. Linus is part of a different community. That's kind of like saying the US government doesn't work because Osama Bin Laden disagrees with people inside it -- implying that Osama is part of the government? WTF?
Let's see... people aren't paid for it, yadda yadda... Not even going to argue with this one, because it's plainly retarded. There is such a thing as volunteer work. Just because it kicked your ass at SCO doesn't invalidate it for the rest of us.
And no, not everyone using Linux will be effected -- in fact, the Linux kernel itself is not affected, and probably never will be. Or would you like to start talking about specific distros now?
Oh, and it's a threat to intellectual property... how? If you don't like it, don't license under it. And frankly, I'm not surprised that the FSF doesn't listen to you.
Well, securing a desktop that only has to run Firefox -- not even a full window manager -- seems a lot easier than securing a desktop that has to run a bunch of apps.
Also puts more responsibility on you -- for example, you now have to run the fileserver, or sacrifice the ability of an employee to sit down at any terminal.
Personally, I'd do it all in-house, but this is a way of outsourcing to Google and only having to maintain a very simple disk image and a bunch of extremely lightweight desktop machines. Bonus is if you change your mind and have to migrate to something else, or even back to Windows, all your stuff is already there, you don't have to convert a bunch of opendocument stuff to something else. It's not hard to see the attraction.
Some sites are actually fairly artistic and tastefully done.
Some sites are pure smut, but are at least honest -- you know up front how much it'll cost you, and what you'll be getting.
And some sites are pure crap -- typosquatters, thumbnail galleries, nothing but piles of ads and spyware.
There's something amusing about saying "I just made a fool out of you, and I'm a 20-year-old web developer from Iowa!"
Point here is that if you're replacing the flash with RAM, instead of with disk, then it's already on anyway. If anything, it's faster than the Flash drive -- Flash has better seek time and startup time, but worse throughput.
Huh.
Did not mean it to come off as hate. I will have to try that, though. Put it to sleep, wake it via usb mouse/keyboard?
Although plugging in the monitor did not seem to wake it, if I remember, and I imagine your Powerbook is of a different generation than mine.
And I would do that how? Wake-on-LAN?
You do realize the power button is next to the keyboard, inside the clamshell, right?
I guess I could try turning it on and quickly closing the lid, or actually doing wake-on-lan (set top box)... Probably easier just to cover the magnet.