It uses the RT kernel which should make Amarok run better.
Erm... no, Amarok 2 has absolutely no transcoding support. As in, with Amarok 1, I can keep my music collection in flac, and it'll play in flac, and it'll transcode to mp3 before it puts it on an iPod.
No kernel is magically going to add that.
For what it's worth, that was actually broken behavior on Amarok 1, too -- rather than letting me choose what to transcode to, it went by some assumption of the preferred format for the device. Apparently, earlier versions had this as a configurable option -- I should have been able to choose to transcode to AAC, rather than MP3.
However, this bug has been closed "wontfix" as it is in Amarok 1, and as this functionality will be completely rewritten for Amarok 2 (eventually), no one wants to fix it in the existing, stable version.
This has been my continuous experience with KDE4, and especially Kubuntu -- ripping out stuff that worked (KNetworkManager) and replacing it with stuff that will eventually work in some future release (the NetworkManager Plasmoid). Unfortunately for me, I've become addicted to some of the cool new features of KDE4, like the ability to (gasp!) rotate PDFs to view sideways -- stuff that very likely won't be backported.
I don't mind KDE4 being cool and new and not KDE3. I don't mind having to learn a new, better way of doing things. I do mind not being able to configure it to work the way KDE3 did, and I do mind large chunks of missing features and the ability to run all day without something crashing.
I'm going to chime in with everyone else and point out that while instantaneous teleportation to anywhere probably wouldn't work -- it would make the world feel smaller, and make it much more difficult to build any sort of a decent dungeon -- having some sort of teleportation is just useful.
Teleportation in Nexus TK works like so: At any given point, you're either in Vortex (high-level hunting area), or you're in one of three kingdoms. In each of these places, there are four gates -- north, south, east, and west. And you have a spell which takes you to these places, instantly.
There's also your home point -- could be an inn, your house, or a subpath area. Use a yellow scroll (costs one coin; absurdly cheap) and you teleport there instantly. That's not a homestone with a 60 second wait -- that's an instantaneous effect, zero cooldown spell.
Travel between kingdoms is usually a few steps (no more than a 10-20 second walk) from the North Gate of a given kingdom, and maybe another ten seconds to switch servers. That same system also provides shortcuts to specific places within kingdoms.
All of this is in the large, registered player, post-level-50 content. They recently added an area (Tangun) for level 50 and under, where players are essentially trapped in a single large map. Yet even here, teleportation to the "home point" within this map is possible, and you can pick up a horse at about level 2, and it'll take maybe five minutes to ride around that entire map, if that.
Hell, even clans have crafting areas, and often various instantaneous portals from the clan hall to various points of interest.
Now, it's not WoW, but I honestly don't see the point in it taking 20 minutes to get anywhere, unless the act of getting there is somehow part of a quest. Whether the world feels small depends mostly on what you do in it -- if you're always going to the same places, yes, it seems small, so stop doing that.
The way to make your world seem larger is content, not gimmicks like slow portals.
And define "kowtow". I just want them to stop doing wild and crazy things, and bring it up to the level of KDE3.
Examples of stuff that still doesn't work on Kubuntu Jaunty: About half the wireless networks I try to connect to, the brightness keys on my laptop, transcoding in Amarok, switch compositing on and off more than once or twice and compositing slows to a crawl, with a high chance of krunner or plasma crashing.
I bought a Powerbook, for that reason. I figured, I'd never run Windows on it, so may as well put Linux on the best laptop ever, right?
Didn't work too well. I never quite got it working, and just ended up using OS X.
In fact, from personal experience, the reason people choose Macs seems to have less to do with the overall UI, and more to do with specific things Just Working that Just Don't on Linux. Example: Maybe it's gotten better, and there's a nice GUI for this somewhere, but when I plug in a second monitor to my laptop, I restart my X server -- I could never quite get Xinerama or the nvidia stuff to cooperate without a restart.
Contrast this to a Macbook -- just plug it in, and it works. Open System Settings if you want it to behave other than as a clone.
So, I still use Linux, and I really don't get the people who would be into open source and use an iPhone, but I can certainly see why people would choose a Mac. Everything just works, just about all the commercial software you want, and a decent (not great, but decent) Unix under the hood for development.
What, irrational people can't have contradictory views? (For that matter, who says it's the same people seeing them as "the enemy", and trying to protect them?)
On the other hand, I would say they aren't quite contradictory. The paranoia is that they could become The Enemy at any moment, so we'd better make sure they don't see Janet Jackson's nipple, because it'll warp their fragile little minds, and before you know it, there'll be a school shooting...
Oh, I'm not saying it's a good position, only that it can be made internally consistent.
Personally, I'd be more than happy with a Desktop Environment that was, say, 5 years old, without bells, whistles, or Compiz, but was *maintained* well -- nay, maintained *aggressively* -- in order to have almost every bug squashed.
Pick up an Ubuntu LTS release. Those last 3 years, at least.
Ubuntu sees the x.04 ("Long Term Support") releases as stable, and the x.10 releases as developmental.
Wrong. LTS has nothing to do with.04 vs.10.
More importantly, normal Ubuntu doesn't make this distinction -- they do see the other releases as incremental improvements, and on vanilla Ubuntu, this is often true. It's Kubuntu that's been royally fucking these up.
Sure it has some known bugs (the static IP issue mentioned above is one)
Not the only one.
8.10 broke bluetooth. Didn't fix it for about two months. During this time, the standard response was "Well, you could run the Gnome bluetooth applet!"
9.04 fucked up network management pretty thoroughly. Issues I've had: WPA with a hex key is broken for me. (Suggested solution? Run the Gnome NetworkManager applet.) Also, clicking on a wireless network requires me to create and save an entry, even if it's an open network. Also, clicking on one which has an entry will create a duplicate entry, require me to re-enter the password, etc.
Yeah, from what I can tell, the way this is supposed to work is that I have to add every single network (ever!) to my list of networks, and sort them by priority, and either have them autoconnect, or click the generic "connect" button. No way to just choose a network and have it do what's expected.
Oh, and Amarok 2 seems to completely ignore whatever was in my Amarok 1 database, rebuilding my collection from scratch (ignoring podcasts, playlists, etc), and is missing basic functionality like sorting and transcoding. Yet a transcoding bug isn't fixed in Amarok 1, because everyone's working on Amarok 2.
Some day, I'm going to have to take a weekend and just do nothing but file bug reports, because that's how shitty KDE4 has been for me. Most of it is probably Kubuntu's fault, but then, Kubuntu didn't have a lot to work with.
I, for one, find it puzzling why both Fedora and Ubuntu continue to put GNOME first with KDE as the also-ran.
Probably because KDE has been royally screwing over loyal users (like me) with these half-assed releases. KDE 3 doesn't get fixed because everyone's working on KDE 4, which doesn't work yet.
Seriously, scroll up.
Contrast this to Ubuntu on GNOME, where stuff just works to the point where when a piece of KDE works, I can replace it with GNOME. Why am I using KDE again?
Now, I do refer to the whole OS as "Linux", or, more often, "Ubuntu". However, I don't think Kleenex and Xerox are good examples. Velcro is much better -- but that was also an entirely new invention; Linux is a Unix, which is a class of Operating Systems, and those are nothing new.
It does something, but not nearly what you'd expect. Play the exact same video file in Flash and in VLC, and you'll notice an order of magnitude (or two!) difference in performance.
And I'm pretty sure Flash is not using the hardware h.264 decoders that some devices are shipping with.
However, the people designing SSDs have no ability to force that change. They have to play the hand they're dealt, and that includes crufty old BIOS that nobody in their right mind would trust any further than they absolutely have to.
I'm not suggesting that they should replace the BIOS on the mainboard, except perhaps for laptops. But what about things like PXE? Other hardware, including controllers, have been built with a way to at least boot off of them...
But, I'm probably out of my depth here.
But if they're going to insist on hiding it I'd rather they do so behind a very well defined API and protocol fully isolated from my kernel except at that well defined interface. Preferably an interface with a comprehensive pass/fail compliance test.
I would agree with that, but I would still prefer it be done in software.
The alternative is a binary blob that taints my kernel and potentially scribbles all over RAM.
It could potentially be just as isolated. That would take some work, though.
The big shortcoming was that there was nothing to keep a compartment from hogging all of the RAM and CPU.
I thought there were already mechanisms to provide per-user limits to those?
Because BIOS routines are still written for real mode.
Ew. That seems like something that should be fixed.
Beyond that, all modern commercial BIOS are a dreadful mess filled with binary patches and cruft.
That's really not a good reason, considering there is a modern, open source BIOS -- Coreboot, formerly LinuxBIOS. I see no reason vendors couldn't adopt that, and start extending it.
Usually it's a disaster even if it only has to support a single architecture. I'd hate to see one meant to run on any OS and any CPU.
nVidia claims something like 90-95% of the code in their video drivers is shared between all platforms.
The drive controller, etc are a decentish place to hide their valuable IPee
Bullshit. People have been "hiding" that IP in software, too. If there's a reason for people to reverse-engineer it, they will, anyway.
and maintain a well defined and well understood interface that's already supported everywhere.
Well, mostly everywhere. But I can see the appeal, there. It is, however, an interface with some shortcomings...
On the other hand, that implies the kernel interfaces should be similarly well defined and well understood. How difficult is it to present a Volume under Windows, or a block device under Linux? Consider that FUSE interfaces already exist for Linux and OS X -- surely a POSIX filesystem API is more difficult than a block API?
I'd have somewhat less trouble with this idea if it was possible to bypass that abstraction layer and use the raw device, for filesystems and OSes that can take full advantage of it. But it's presented as this SATA black box, to which we're slowly starting to add features that were there already on more primitive devices.
You can get an IDE controller for practically any platform. I don't think you can even buy a mainboard that doesn't have one.
I'm pretty sure mine doesn't. Most SSDs, including mine, are SATA.
Meanwhile, it's not like you could get rid of glue logic anyway.
Fair enough. However, I think this goes beyond the amount of glue logic we want.
I may have made this analogy before, but it's a bit like hardware RAID. Some slight performance gain that just becomes irrelevant in a generation or two, and older/dumber OSes can pretend it's just a single hard drive. Downsides are, you're paying for extra, unnecessary hardware, the logic in the RAID controller is probably inferior, and the RAID layer really can't talk to the filesystem layer, preventing some of the cooler features of ZFS.
Speaking of which, you don't want the CPU twiddling it's thumbs waiting for that state machine to complete an erase operation (very slow). Issuing a TRIM command is fire and forget.
No, but is there a reason the CPU has to? I suppose that depends on the interface used...
I should point out that chroot can be trivially broken out of.
True, but that's largely because people never tried to make it into a jail, and instead focused on virtual machines.
Of course, I'm guessing that you can only really break that jail as root, correct?
Jail is tougher, but it's easy to accidentally leave a back door.
The same could be said of any system, including virtualization.
Really, I think virtualization is a similarly brutal hack, that may be justified by the amount of work it saves, but really, we should just do the work.
Example: Virtual machines can be migrated from one physical machine to another, without anything inside the VM even noticing. However, LinuxPMI already does this to some extent with individual processes. It's a hard problem, but not impossible.
First, this is not a cabinet position. This is fucking Bozeman, Montana, which no one had heard of until they pulled this stunt.
Second, who watches the watchers?
Third, define "nothing to hide"? As a simple example, I don't think my body is horrible, though it could certainly be better. That doesn't mean I want to be strip-searched to get on the bus to go to work.
It's not about whether you have anything "suspicious" worth hiding. It's about whether you have anything you'd consider private. There's a reason privacy is part of the universal declaration of human rights.
I, for one, prefer it to be a hardware function. That could be from previous bad experience with software based wear leveling back in the old days.
And others have had bad experiences with hardware based wear leveling.
The difference is, put it in the OS, and it can actually be patched. Put it in the firmware, and it can theoretically be patched, but probably only by the manufacturer.
The other issue I have with software doing wear leveling is the added processor overhead incurred. This may not matter for modern day desktop systems, but it still a burden for embedded devices.
For an embedded device, I can understand throwing another processor on there to do this -- because that's basically what you're advocating. But I'm still skeptical -- is the power draw from all that extra circuitry inside the SSD, worth the power savings by using just a little bit less CPU?
No OS has actually used the BIOS for I/O for a very longgggggg time. It's just too slow and too crappy to contemplate.
I'm curious why, but ok.
The BIOS part of the fakeraid goes away once the OS loads. The driver does all the work.
What I'm curious about is why it couldn't use the BIOS if no driver was provided. And if a driver is provided, hey, problem solved.
That's why it's being done in the drive firmware.
So... It's really easier to develop firmware, and a bunch of extra controller logic, than a cross-platform driver? Really?
The question is WHY. It's not likely to buy you anything that the TRIM command plus firmware on the drive doesn't already do.
The answer is, because the OS can already do these things, and it removes a whole layer of complexity -- not to mention wholly unnecessary hardware.
It's like hardware RAID. Faster, for now, and more compatible, maybe. Also way less flexible, more moving parts to fail, and things you actually can't do with it.
As an example: If the OS is doing wear-leveling, a new write to a given chunk of a file is going to go to a new location on disk. The filesystem could potentially remember the old location, and not pre-erase it, but actually be able to rewind to that point, if needed, until something else overwrites it.
Yes, you can do a log-based FS on top of the firmware, but now you're basically implementing the same logic on top of that -- write everything to the end of the disk, ultimately recover unused spaces near the beginning -- as I understand it, this is ideal behavior for wear-leveling. Why implement it twice?
I suppose it frustrates me for the same reason virtualization frustrates me. It has the same feel as creating a file, then pretending that's a block device, so that the virtual machine can run its own filesystem on top of it -- and for what? Mostly, so you can give people "root" access, while restricting them to a sandbox. Tools like chroot -- and, ultimately, BSD Jails -- should be able to do this job -- there's no reason you shouldn't be using some directory on the host filesystem.
Yet we add this extra layer of wasteful cruft, to avoid having to do some hard engineering.
Well, I am assuming these things hates data written over and over to same spot.
Somewhat, but it can wear-level that anyway. What I would assume it hates is tiny amounts written over and over, rather than larger chunks.
Trust me, for a consumer laptop which is good enough to consider SSD, fsck_hfs doesn't take that long.
It's not just about the length of time, it's about the possibility of corruption. FSCK is basically trying to recover after corruption has occurred. Journals prevent corruption from occurring in the first place.
Yes, wear leveling is done by the SSD itself, which is a total waste. The OS already has to do allocation; there's no reason a filesystem can't do wear leveling, too, and several Linux filesystems do.
There's also the block size itself, and the fact that the OS is optimized to place things sequentially, which is completely pointless -- especially if it tries to defrag -- when the device is an SSD.
And no, it won't put repair software out of business. If anything, it'll generate more business -- some SSDs go into read-only mode when they can't write, but some just stop working altogether, meaning if you want your data back, you now have to pay someone to take apart the drive and recover it for you.
That, and with people disabling journals to get more performance and a longer lifetime, we're back to the old problem of OS crash or power pulled could mean a corrupt filesystem.
Slashdot Mirror
You're right. In fact, that's one reason I use Linux -- when things go wrong, I can fix them. When things go wrong with a Mac, I'm pretty much lost.
However, the fact that I still have to edit xorg.conf is pretty embarrassing.
It uses the RT kernel which should make Amarok run better.
Erm... no, Amarok 2 has absolutely no transcoding support. As in, with Amarok 1, I can keep my music collection in flac, and it'll play in flac, and it'll transcode to mp3 before it puts it on an iPod.
No kernel is magically going to add that.
For what it's worth, that was actually broken behavior on Amarok 1, too -- rather than letting me choose what to transcode to, it went by some assumption of the preferred format for the device. Apparently, earlier versions had this as a configurable option -- I should have been able to choose to transcode to AAC, rather than MP3.
However, this bug has been closed "wontfix" as it is in Amarok 1, and as this functionality will be completely rewritten for Amarok 2 (eventually), no one wants to fix it in the existing, stable version.
This has been my continuous experience with KDE4, and especially Kubuntu -- ripping out stuff that worked (KNetworkManager) and replacing it with stuff that will eventually work in some future release (the NetworkManager Plasmoid). Unfortunately for me, I've become addicted to some of the cool new features of KDE4, like the ability to (gasp!) rotate PDFs to view sideways -- stuff that very likely won't be backported.
I don't mind KDE4 being cool and new and not KDE3. I don't mind having to learn a new, better way of doing things. I do mind not being able to configure it to work the way KDE3 did, and I do mind large chunks of missing features and the ability to run all day without something crashing.
If we're talking about open source developers, that's two reasons:
Firefox is open source, and unless there's been a lot of progress made lately, Firebug is still the best tool of its kind.
I'm going to chime in with everyone else and point out that while instantaneous teleportation to anywhere probably wouldn't work -- it would make the world feel smaller, and make it much more difficult to build any sort of a decent dungeon -- having some sort of teleportation is just useful.
Teleportation in Nexus TK works like so: At any given point, you're either in Vortex (high-level hunting area), or you're in one of three kingdoms. In each of these places, there are four gates -- north, south, east, and west. And you have a spell which takes you to these places, instantly.
There's also your home point -- could be an inn, your house, or a subpath area. Use a yellow scroll (costs one coin; absurdly cheap) and you teleport there instantly. That's not a homestone with a 60 second wait -- that's an instantaneous effect, zero cooldown spell.
Travel between kingdoms is usually a few steps (no more than a 10-20 second walk) from the North Gate of a given kingdom, and maybe another ten seconds to switch servers. That same system also provides shortcuts to specific places within kingdoms.
All of this is in the large, registered player, post-level-50 content. They recently added an area (Tangun) for level 50 and under, where players are essentially trapped in a single large map. Yet even here, teleportation to the "home point" within this map is possible, and you can pick up a horse at about level 2, and it'll take maybe five minutes to ride around that entire map, if that.
Hell, even clans have crafting areas, and often various instantaneous portals from the clan hall to various points of interest.
Now, it's not WoW, but I honestly don't see the point in it taking 20 minutes to get anywhere, unless the act of getting there is somehow part of a quest. Whether the world feels small depends mostly on what you do in it -- if you're always going to the same places, yes, it seems small, so stop doing that.
The way to make your world seem larger is content, not gimmicks like slow portals.
Citation needed.
And define "kowtow". I just want them to stop doing wild and crazy things, and bring it up to the level of KDE3.
Examples of stuff that still doesn't work on Kubuntu Jaunty: About half the wireless networks I try to connect to, the brightness keys on my laptop, transcoding in Amarok, switch compositing on and off more than once or twice and compositing slows to a crawl, with a high chance of krunner or plasma crashing.
I bought a Powerbook, for that reason. I figured, I'd never run Windows on it, so may as well put Linux on the best laptop ever, right?
Didn't work too well. I never quite got it working, and just ended up using OS X.
In fact, from personal experience, the reason people choose Macs seems to have less to do with the overall UI, and more to do with specific things Just Working that Just Don't on Linux. Example: Maybe it's gotten better, and there's a nice GUI for this somewhere, but when I plug in a second monitor to my laptop, I restart my X server -- I could never quite get Xinerama or the nvidia stuff to cooperate without a restart.
Contrast this to a Macbook -- just plug it in, and it works. Open System Settings if you want it to behave other than as a clone.
So, I still use Linux, and I really don't get the people who would be into open source and use an iPhone, but I can certainly see why people would choose a Mac. Everything just works, just about all the commercial software you want, and a decent (not great, but decent) Unix under the hood for development.
You already have more than one designer -- at the very least, that Mac is going to have Firefox on it, which isn't made by Apple.
Never mind that you've still got several different UIs from Apple itself -- the iTunes brushed metal look, the curvy Aqua look..
What, irrational people can't have contradictory views? (For that matter, who says it's the same people seeing them as "the enemy", and trying to protect them?)
On the other hand, I would say they aren't quite contradictory. The paranoia is that they could become The Enemy at any moment, so we'd better make sure they don't see Janet Jackson's nipple, because it'll warp their fragile little minds, and before you know it, there'll be a school shooting...
Oh, I'm not saying it's a good position, only that it can be made internally consistent.
Binary API stability. Applications compiled against the KDE 4.0 libs
Then call it lbikde4.0.
Or call it a release candidate.
I should clarify: Name a good reason to release it as 4.0 that couldn't be better accomplished through other, less confusing means.
the KDE devs had perfectly good reasons to release it as 4.0
Name one.
Personally, I'd be more than happy with a Desktop Environment that was, say, 5 years old, without bells, whistles, or Compiz, but was *maintained* well -- nay, maintained *aggressively* -- in order to have almost every bug squashed.
Pick up an Ubuntu LTS release. Those last 3 years, at least.
Ubuntu sees the x.04 ("Long Term Support") releases as stable, and the x.10 releases as developmental.
Wrong. LTS has nothing to do with .04 vs .10.
More importantly, normal Ubuntu doesn't make this distinction -- they do see the other releases as incremental improvements, and on vanilla Ubuntu, this is often true. It's Kubuntu that's been royally fucking these up.
Sure it has some known bugs (the static IP issue mentioned above is one)
Not the only one.
8.10 broke bluetooth. Didn't fix it for about two months. During this time, the standard response was "Well, you could run the Gnome bluetooth applet!"
9.04 fucked up network management pretty thoroughly. Issues I've had: WPA with a hex key is broken for me. (Suggested solution? Run the Gnome NetworkManager applet.) Also, clicking on a wireless network requires me to create and save an entry, even if it's an open network. Also, clicking on one which has an entry will create a duplicate entry, require me to re-enter the password, etc.
Yeah, from what I can tell, the way this is supposed to work is that I have to add every single network (ever!) to my list of networks, and sort them by priority, and either have them autoconnect, or click the generic "connect" button. No way to just choose a network and have it do what's expected.
Oh, and Amarok 2 seems to completely ignore whatever was in my Amarok 1 database, rebuilding my collection from scratch (ignoring podcasts, playlists, etc), and is missing basic functionality like sorting and transcoding. Yet a transcoding bug isn't fixed in Amarok 1, because everyone's working on Amarok 2.
Some day, I'm going to have to take a weekend and just do nothing but file bug reports, because that's how shitty KDE4 has been for me. Most of it is probably Kubuntu's fault, but then, Kubuntu didn't have a lot to work with.
I, for one, find it puzzling why both Fedora and Ubuntu continue to put GNOME first with KDE as the also-ran.
Probably because KDE has been royally screwing over loyal users (like me) with these half-assed releases. KDE 3 doesn't get fixed because everyone's working on KDE 4, which doesn't work yet.
Seriously, scroll up.
Contrast this to Ubuntu on GNOME, where stuff just works to the point where when a piece of KDE works, I can replace it with GNOME. Why am I using KDE again?
I generally say "tissue", "copy", or "copier".
Now, I do refer to the whole OS as "Linux", or, more often, "Ubuntu". However, I don't think Kleenex and Xerox are good examples. Velcro is much better -- but that was also an entirely new invention; Linux is a Unix, which is a class of Operating Systems, and those are nothing new.
The problem is, how will you obtain the rights needed to distribute the proprietary versions with Firefox, Chrome, Safari, and every major browser?
Because if they don't come with the browser, we're going to have the same problems the old-school QuickTime/WMV/etc had.
It does something, but not nearly what you'd expect. Play the exact same video file in Flash and in VLC, and you'll notice an order of magnitude (or two!) difference in performance.
And I'm pretty sure Flash is not using the hardware h.264 decoders that some devices are shipping with.
Check out http://youtube.com/html5
I'm pretty sure that's vorbis/theora.
However, the people designing SSDs have no ability to force that change. They have to play the hand they're dealt, and that includes crufty old BIOS that nobody in their right mind would trust any further than they absolutely have to.
I'm not suggesting that they should replace the BIOS on the mainboard, except perhaps for laptops. But what about things like PXE? Other hardware, including controllers, have been built with a way to at least boot off of them...
But, I'm probably out of my depth here.
But if they're going to insist on hiding it I'd rather they do so behind a very well defined API and protocol fully isolated from my kernel except at that well defined interface. Preferably an interface with a comprehensive pass/fail compliance test.
I would agree with that, but I would still prefer it be done in software.
The alternative is a binary blob that taints my kernel and potentially scribbles all over RAM.
It could potentially be just as isolated. That would take some work, though.
The big shortcoming was that there was nothing to keep a compartment from hogging all of the RAM and CPU.
I thought there were already mechanisms to provide per-user limits to those?
Because BIOS routines are still written for real mode.
Ew. That seems like something that should be fixed.
Beyond that, all modern commercial BIOS are a dreadful mess filled with binary patches and cruft.
That's really not a good reason, considering there is a modern, open source BIOS -- Coreboot, formerly LinuxBIOS. I see no reason vendors couldn't adopt that, and start extending it.
Usually it's a disaster even if it only has to support a single architecture. I'd hate to see one meant to run on any OS and any CPU.
nVidia claims something like 90-95% of the code in their video drivers is shared between all platforms.
The drive controller, etc are a decentish place to hide their valuable IPee
Bullshit. People have been "hiding" that IP in software, too. If there's a reason for people to reverse-engineer it, they will, anyway.
and maintain a well defined and well understood interface that's already supported everywhere.
Well, mostly everywhere. But I can see the appeal, there. It is, however, an interface with some shortcomings...
On the other hand, that implies the kernel interfaces should be similarly well defined and well understood. How difficult is it to present a Volume under Windows, or a block device under Linux? Consider that FUSE interfaces already exist for Linux and OS X -- surely a POSIX filesystem API is more difficult than a block API?
I'd have somewhat less trouble with this idea if it was possible to bypass that abstraction layer and use the raw device, for filesystems and OSes that can take full advantage of it. But it's presented as this SATA black box, to which we're slowly starting to add features that were there already on more primitive devices.
You can get an IDE controller for practically any platform. I don't think you can even buy a mainboard that doesn't have one.
I'm pretty sure mine doesn't. Most SSDs, including mine, are SATA.
Meanwhile, it's not like you could get rid of glue logic anyway.
Fair enough. However, I think this goes beyond the amount of glue logic we want.
I may have made this analogy before, but it's a bit like hardware RAID. Some slight performance gain that just becomes irrelevant in a generation or two, and older/dumber OSes can pretend it's just a single hard drive. Downsides are, you're paying for extra, unnecessary hardware, the logic in the RAID controller is probably inferior, and the RAID layer really can't talk to the filesystem layer, preventing some of the cooler features of ZFS.
Speaking of which, you don't want the CPU twiddling it's thumbs waiting for that state machine to complete an erase operation (very slow). Issuing a TRIM command is fire and forget.
No, but is there a reason the CPU has to? I suppose that depends on the interface used...
I should point out that chroot can be trivially broken out of.
True, but that's largely because people never tried to make it into a jail, and instead focused on virtual machines.
Of course, I'm guessing that you can only really break that jail as root, correct?
Jail is tougher, but it's easy to accidentally leave a back door.
The same could be said of any system, including virtualization.
Really, I think virtualization is a similarly brutal hack, that may be justified by the amount of work it saves, but really, we should just do the work.
Example: Virtual machines can be migrated from one physical machine to another, without anything inside the VM even noticing. However, LinuxPMI already does this to some extent with individual processes. It's a hard problem, but not impossible.
And an obvious
First, this is not a cabinet position. This is fucking Bozeman, Montana, which no one had heard of until they pulled this stunt.
Second, who watches the watchers?
Third, define "nothing to hide"? As a simple example, I don't think my body is horrible, though it could certainly be better. That doesn't mean I want to be strip-searched to get on the bus to go to work.
It's not about whether you have anything "suspicious" worth hiding. It's about whether you have anything you'd consider private. There's a reason privacy is part of the universal declaration of human rights.
At least get your zealotry straight.
The "bearded GNU freaks" wouldn't dare touch World of Warcraft. It's proprietary! It certainly isn't "Free as in Freedom"!
The fact that such actions are actually reasonably justifiable from their sacred texts doesn't help their case.
I, for one, prefer it to be a hardware function. That could be from previous bad experience with software based wear leveling back in the old days.
And others have had bad experiences with hardware based wear leveling.
The difference is, put it in the OS, and it can actually be patched. Put it in the firmware, and it can theoretically be patched, but probably only by the manufacturer.
The other issue I have with software doing wear leveling is the added processor overhead incurred. This may not matter for modern day desktop systems, but it still a burden for embedded devices.
For an embedded device, I can understand throwing another processor on there to do this -- because that's basically what you're advocating. But I'm still skeptical -- is the power draw from all that extra circuitry inside the SSD, worth the power savings by using just a little bit less CPU?
No OS has actually used the BIOS for I/O for a very longgggggg time. It's just too slow and too crappy to contemplate.
I'm curious why, but ok.
The BIOS part of the fakeraid goes away once the OS loads. The driver does all the work.
What I'm curious about is why it couldn't use the BIOS if no driver was provided. And if a driver is provided, hey, problem solved.
That's why it's being done in the drive firmware.
So... It's really easier to develop firmware, and a bunch of extra controller logic, than a cross-platform driver? Really?
The question is WHY. It's not likely to buy you anything that the TRIM command plus firmware on the drive doesn't already do.
The answer is, because the OS can already do these things, and it removes a whole layer of complexity -- not to mention wholly unnecessary hardware.
It's like hardware RAID. Faster, for now, and more compatible, maybe. Also way less flexible, more moving parts to fail, and things you actually can't do with it.
As an example: If the OS is doing wear-leveling, a new write to a given chunk of a file is going to go to a new location on disk. The filesystem could potentially remember the old location, and not pre-erase it, but actually be able to rewind to that point, if needed, until something else overwrites it.
Yes, you can do a log-based FS on top of the firmware, but now you're basically implementing the same logic on top of that -- write everything to the end of the disk, ultimately recover unused spaces near the beginning -- as I understand it, this is ideal behavior for wear-leveling. Why implement it twice?
I suppose it frustrates me for the same reason virtualization frustrates me. It has the same feel as creating a file, then pretending that's a block device, so that the virtual machine can run its own filesystem on top of it -- and for what? Mostly, so you can give people "root" access, while restricting them to a sandbox. Tools like chroot -- and, ultimately, BSD Jails -- should be able to do this job -- there's no reason you shouldn't be using some directory on the host filesystem.
Yet we add this extra layer of wasteful cruft, to avoid having to do some hard engineering.
Well, I am assuming these things hates data written over and over to same spot.
Somewhat, but it can wear-level that anyway. What I would assume it hates is tiny amounts written over and over, rather than larger chunks.
Trust me, for a consumer laptop which is good enough to consider SSD, fsck_hfs doesn't take that long.
It's not just about the length of time, it's about the possibility of corruption. FSCK is basically trying to recover after corruption has occurred. Journals prevent corruption from occurring in the first place.
Way to completely miss the point.
Yes, wear leveling is done by the SSD itself, which is a total waste. The OS already has to do allocation; there's no reason a filesystem can't do wear leveling, too, and several Linux filesystems do.
There's also the block size itself, and the fact that the OS is optimized to place things sequentially, which is completely pointless -- especially if it tries to defrag -- when the device is an SSD.
And no, it won't put repair software out of business. If anything, it'll generate more business -- some SSDs go into read-only mode when they can't write, but some just stop working altogether, meaning if you want your data back, you now have to pay someone to take apart the drive and recover it for you.
That, and with people disabling journals to get more performance and a longer lifetime, we're back to the old problem of OS crash or power pulled could mean a corrupt filesystem.