Out-of-the-Box, Ubuntu 14.04 LTS To Support TRIM On SSDs

← Back to Stories (view on slashdot.org)

Out-of-the-Box, Ubuntu 14.04 LTS To Support TRIM On SSDs

Posted by timothy on Saturday December 21, 2013 @12:22PM from the keep-it-snappy dept.

First time accepted submitter Maurits van der Schee writes "Where in older versions you had to add a cron job calling "fstrim" or mounting with the "discard" option in fstab, the new LTS (Long Term Stable) version of Ubuntu Linux will automatically enable TRIM for your SSD. Good news for hardware enthusiasts!"

133 comments

Min score:

Reason:

Sort:

Stable? by Anonymous Coward · 2013-12-21 12:26 · Score: 5, Informative

"LTS is an abbreviation for "Long Term Support"."
1. Re:Stable? by Anonymous Coward · 2013-12-23 06:11 · Score: 0
  
  Yep, "Ubuntu" and "Stable" are two completely different ends of the spectrum
I say, Welcome to this Decade already! by Anonymous Coward · 2013-12-21 12:27 · Score: 0

We were wondering ... not!
It's Long-term support... by Anonymous Coward · 2013-12-21 12:29 · Score: 1

Aside from this being old news, along with the typical comments about Windows 7 having the feature since introduction.
1. Re:It's Long-term support... by Anonymous Coward · 2013-12-21 12:35 · Score: 2, Informative
  
  along with the typical comments about Windows 7 having the feature since introduction
  Well, let me be that guy... ;)
  Windows implements TRIM command for more than just file delete operations. The TRIM operation is fully integrated with partition- and volume-level commands like format and delete, with file system commands relating to truncate and compression, and with the Volume Snapshot feature.[1]
2. Re:It's Long-term support... by fisted · 2013-12-21 15:17 · Score: 0
  
  Cool, so they're only how many years behind?
  
  --
  CLI paste? paste.pr0.tips!
3. Re:It's Long-term support... by Anonymous Coward · 2013-12-21 15:36 · Score: 0
  
  It sounds like Linux is four years behind.
"Good news for hardware enthusiasts!"... by Anonymous Coward · 2013-12-21 12:30 · Score: 0

or anyone with a SSD!
1. Re: "Good news for hardware enthusiasts!"... by Anonymous Coward · 2013-12-21 12:34 · Score: 0
  
  No kidding. All I use in systems I build now are SSDs. Even low end. Most people don't need all that space to hoard files and would rather have the performance.
2. Re: "Good news for hardware enthusiasts!"... by Anonymous Coward · 2013-12-21 14:04 · Score: 0
  
  No one I know, that's not a gamer or developer, uses a desktop anymore.
3. Re: "Good news for hardware enthusiasts!"... by Gadget_Guy · 2013-12-21 14:23 · Score: 4, Insightful
  
  ...or typesetters & typists, accountants, video editors, music composers, engineers & architects, etc. In fact, anyone who produces, rather than consumes will tend to use computers as their main system. SSDs work nicely for all of them, if only to store the OS and program files.
  That you only know gamers and developers says more about the company you keep rather than what technology is used out there. It is true that tablets and smart phone sales are on the rise and PC sales are declining, but that doesn't mean that people have stopped using their old computers.
4. Re: "Good news for hardware enthusiasts!"... by Anonymous Coward · 2013-12-21 16:59 · Score: 1
  
  I'm still using a dual socket quad core Xeon from 2006. Plenty of speed. Not sure when I will need more. I have a second desktop that is a 2700k. Just as fast. Only upgrades I do are ssds or 4tb drives. I will run these until they just stop. 5 more years, maybe 10... Whatever.
5. Re: "Good news for hardware enthusiasts!"... by Mashdar · 2013-12-22 04:30 · Score: 1
  
  Don't worry. Norton will take care of your computer soon.
Defeats pleasure of unnecessary labour by Twinbee · 2013-12-21 12:33 · Score: 4, Funny

But surely this defeats the perceived satisfaction of tweaking and fixing it all up manually? Where's the fun in that?

--
Why OpalCalc is the best Windows calc
1. Re:Defeats pleasure of unnecessary labour by TeknoHog · 2013-12-21 12:40 · Score: 4, Interesting
  
  But surely this defeats the perceived satisfaction of tweaking and fixing it all up manually? Where's the fun in that?
  If that's your thing, use Gentoo instead. At least that's what I do. In case you're being sarcastic, the fun IMHO is in learning about your system and understanding why distros make the choices they do. I think my first week with Linux taught me more about computers than years with DOS/Windows, and I still wonder how a Windows machine can be anyone's "Personal Computer".
  
  --
  Escher was the first MC and Giger invented the HR department.
2. Re:Defeats pleasure of unnecessary labour by Anonymous Coward · 2013-12-21 15:17 · Score: 0
  
  Gentoo is fine if you're a sadist, but the rest of us will stick with Slackware. And then there's this and this
3. Re:Defeats pleasure of unnecessary labour by jones_supa · 2013-12-21 15:40 · Score: 1
  
  What are "this" and "this"?
4. Re:Defeats pleasure of unnecessary labour by Anonymous Coward · 2013-12-21 18:55 · Score: 0
  
  > If that's your thing, use Gentoo instead. A
  I'm sorry, I have a day job....
5. Re:Defeats pleasure of unnecessary labour by Anonymous Coward · 2013-12-21 19:48 · Score: 0, Insightful
  
  I strongly disagree. I found my first week with Linux, and subsequent weeks prodding it to make it work like I wanted it to was all about learning how Linux worked, and not much about computers. For example, I needed to learn how to edit the xorg.conf file so I could implement the side buttons on my Logitech mouse at the time (so you can browse back/foward in web sites and file managers without having to move the mouse). In Windows it was bloody easy - it WORKED, even without any special Logitech drivers. In Linux the side buttons didn't do shit until I configured xorg.conf to understand what kind of mouse I had.
  That episode was a good introduction to the problems that occur when going off the beaten track and trying to be "special" (i.e. use Linux on the desktop instead of a incredibly widely supported system like Windows). It's better nowadays - much better in fact. But learning about computers through Linux? Hell no.
6. Re:Defeats pleasure of unnecessary labour by Anonymous Coward · 2013-12-22 00:17 · Score: 0
  
  Gentoo is fine if you're a sadist, but the rest of us will stick with Slackware.
  Slackware is nice and all but what about LFS?
7. Re:Defeats pleasure of unnecessary labour by Anne+Thwacks · 2013-12-22 07:27 · Score: 2
  
  Goatse.sx - You must be new here.
  
  --
  Sent from my ASR33 using ASCII
Taking too long by Anonymous Coward · 2013-12-21 12:36 · Score: 5, Insightful

This is way overdue.
It's also taking too long for file systems that provide snapshot features to become mainstream and default as well. And no, LVM snapshots aren't good enough.
No, I'm not going to write the patches. They wouldn't be accepted in any case. Fundamental features such as the IO stack and file systems are now the exclusive purview of well-heeled outfits like Red Hat, Oracle, Intel, OSDL, etc. and and their stable of full time developers.
They just need to do their jobs and get it done.
1. Re:Taking too long by csirac · 2013-12-21 13:34 · Score: 1
  
  I've been choosing btrfs through the debian installer for at least a couple of years now. Yes, I know it's not as awesome as ZFS, but it still beats mdraid and lvm.
2. Re:Taking too long by profplump · 2013-12-21 13:58 · Score: 1
  
  I'm currently using LVM snapshots for upgrades and backups -- what am I missing compared file system snapshots?
3. Re:Taking too long by darkpixel2k · 2013-12-21 17:31 · Score: 5, Funny
  
  I've been choosing btrfs through the debian installer for at least a couple of years now.
  Dude you so have to try ZFS. It's aweso--
  
  Yes, I know it's not as awesome as ZFS, but it still beats mdraid and lvm.
  Oh--sorry. Got ahead of myself there. Good thing you stopped me in time.
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
4. Re:Taking too long by Anonymous Coward · 2013-12-21 19:04 · Score: 0
  
  Neither mdraid nor lvm are actually filesystems. They're a middle layer in between your disk and your filesystem, to provide an abstraction layer between your disk and your filesystem, to allow aggregation and segregation of the hardware in ways that would require expensive hardware resources to manage. Unfortunately, I'm afraid that many systems personnel have lost site of the fact that both are _pointless_ in virtualized environments, and have no use there where the hardware layer has already been abstracted. It's been incredibly amusing to watch colleagues burning time, and wasting CPU and systems resources, trying to interject additional layers of abstraction in such environments when there's simply no need. Stick to raw disk images for virtualized environments, and throw out mdadm and LVM entirely for virtual guests.
  ZFS and btrfs are a very different toolkits, but are far more useful at the virtual server layer. There is just no point to them in the virtual guest environments unless you want spend CPU cycles pointlessly.
5. Re:Taking too long by jareth-0205 · 2013-12-22 00:57 · Score: 0
  
  Meh, all I can hear is "waaah waaah Give me my free stuff"
6. Re:Taking too long by joel48 · 2013-12-22 06:32 · Score: 1
  
  For single drives yes it seems to work well and so I can give you some advantages over filesystem unaware LVM. However in my experience (last tested in September) it doesn't come anywhere close to mdraid for multiple device setups. The tools don't accurately show the kernel state (drive missing or not) and there are a number of inconsistencies just in hotplugging drives. Oh and that is the only option because you can't even forcibly fail a drive from a RAID1 to replace it.
7. Re:Taking too long by hoggoth · 2013-12-23 05:44 · Score: 1
  
  I'm pretty sure yanking a drive out of a RAID1 bay will "forcibly fail" it.
  
  --
  - For the complete works of Shakespeare: cat /dev/random (may take some time)
Why? by Anonymous Coward · 2013-12-21 12:36 · Score: 0

Why is this "good news for hardware enthusiasts"? If you are a hardware enthusiast and running linux I don't think you really even mind or care about adding one word to fstab.
WHAT THE FUCK ARE YOU DOING?! by Anonymous Coward · 2013-12-21 12:39 · Score: 5, Funny

HOLY FUCK, MAN! JUST WHAT THE HELL DO YOU THINK YOU'RE DOING?!?!?!
This is Slashdot, for crying out loud. How DARE you bring facts and correct information to the discussion here! THAT IS NOT ALLOWED! You just can't do that! FUCK!
1. Re:WHAT THE FUCK ARE YOU DOING?! by voss · 2013-12-21 14:13 · Score: 2
  
  I wish I had a +1 funny mod point for him
2. Re:WHAT THE FUCK ARE YOU DOING?! by johnnys · 2013-12-21 14:37 · Score: 1
  
  What he said!!
  
  --
  Sometimes the "writing on the wall" is blood spatter...
3. Re:WHAT THE FUCK ARE YOU DOING?! by lexman098 · 2013-12-21 15:35 · Score: 1
  
  You don't waste mod points on an AC
4. Re:WHAT THE FUCK ARE YOU DOING?! by Anonymous Coward · 2013-12-21 23:06 · Score: 2, Informative
  
  You don't waste mod points on an AC
  Mod up good ideas. The name (or lack therof) is irrelevant.
TRIM not always good by girlintraining · 2013-12-21 12:41 · Score: 5, Interesting

the new LTS (Long Term Stable) version of Ubuntu Linux will automatically enable TRIM for your SSD. Good news for hardware enthusiasts!"
And terrible news for encryption experts. Enabling TRIM tells your adversary which sectors contain data and which don't. It's a great asset to cryptanalysis and also destroys plausible deniability that there's a filesystem present on the drive, and how much data is present in it -- thus eliminating the "shadow volume" option of Truecrypt and others.

--
#fuckbeta #iamslashdot #dicemustdie
1. Re:TRIM not always good by BitZtream · 2013-12-21 12:51 · Score: 0, Troll
  
  ... Enabling TRIM tells them which sectors HAD data in them.
  So unless you can magically teleport the drive from its location, away from its internal super capacitors designed to ensure unexpected power interruptions aren't a problem .. BEFORE the drive has a chance to act on the trim commands ... then MAYBE you can get SOME data.
  After the drive gets the TRIM command in its buffer, you're SOL. It will most certainly be deleted before you get to it.
  More importantly, if someone is somehow managing to get access to the data about which sectors are being TRIMd .... they've already rooted your machine and have complete control over it, since you know, thats data that only the kernel has access to.
  So basically, the comment you probably thought was incredibly clever ... is just 100% ignorant of reality.
  There is pretty much nothing in your statement that is true. You don't understand how shadow volumes work. You're making up silly scenarios that don't exist for SSDs or HDDs.
  You need more training.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
2. Re:TRIM not always good by Anonymous Coward · 2013-12-21 12:55 · Score: 1
  
  Hmm? trimmed-sectors return all zeroes. Non-written sectors also return all zeroes. SSDs are not exactly well-tailored for encripted volume usage, and that's it.
3. Re:TRIM not always good by Billly+Gates · 2013-12-21 13:13 · Score: 1
  
  Oh please.
  Most users don't want their drives go down to 5 megs per second. Trying to justify your OS doesn't cut it.
  
  --
  http://saveie6.com/
4. Re:TRIM not always good by Anonymous Coward · 2013-12-21 13:32 · Score: 5, Interesting
  
  No, YOU clearly don't know what you're talking about, and yet are arrogant as all hell.
  The problem arises from the fact that while HDDs have only 2 operations (read, write) and therefore have no distinction outside the file-system of what is "free" and what is "allocated", SSDs have 3 (read, write, free), because SSDs label sectors as "free" or "allocated" (that is, the hardware itself, not just the file-system). So for a standard HDD encryption, the procedure goes: overwrite hard drive with random data, create encrypted partition, install OS on encrypted partition (last step optional, of course). What this accomplishes is that an attacker who examines the disk can't tell the difference between what is and isn't written to, since the unwritten data is random and the written data is encrypted (i.e. indistinguishable from random, if done correctly). On a TRIM-enabled SSD though, the OS sees all these unused sectors and proceeds to mark them as Free. That is a huge fucking problem, for the roughly the reasons the GP stated. In particular, it's egregiously bad for users of hidden volumes, since that hidden volume will never be TRIMed, and the attacker who can rubber hose your outer volume can see a chunk of disk that hasn't been trimmed, yet isn't allocated in the partition you gave them. They can now rubber hose THAT partition as well, whereas previously there was no way to know it even existed (in theory at least, the cryptsetup guys don't buy that).
  If you don't believe this is an issue, then ask the Truecrypt devs:
  http://www.truecrypt.org/docs/trim-operation
  or the LUKS/dm-crypt devs:
  http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
  Please be more respectful in the future, as we're wrong more often than we like to think.
5. Re:TRIM not always good by Anonymous Coward · 2013-12-21 13:43 · Score: 0
  
  This is only at the filesystem layer - it won't go through to the block device if the dm-crypt layer doesn't have "allow-discards"
6. Re:TRIM not always good by Anonymous Coward · 2013-12-21 13:47 · Score: 0
  
  Wrong.
  There's 2 ATA feature flags concerning read-after-trim behavior.
  Read Zero after Trim
  and
  Deterministic Read After Trim
  If your SSD doesn't have Read Zero after Trim, it's perfectly free to return the previous data or completely random junk when reading a TRIMed block (note: it *can* return zeros, but it doesn't have to).
  If it doesn't have Deterministic Read After Trim, it can even return different data for successive reads of the same TRIMed block (e.g. you TRIM a block, read it, get the original data, read it again, get random junk, read it again, get zeros).
7. Re:TRIM not always good by Anonymous Coward · 2013-12-21 14:10 · Score: 3, Funny
  
  He can't be wrong though, he's already marked at Score 4: Insightful at the time of this post. And since Slashdotters are so smart and intelligent the score must be correct, right?
  I dunno. Problem is it's hard to know who's right and who's not. All I know is that Windows 7 had TRIM support automatically enabled for SSDs back in 2009 and the leading Linux distro's only finally going to enable it in 2014. No wonder so many people still see Linux as old and not suitable for end-user machines.
8. Re:TRIM not always good by Anonymous Coward · 2013-12-21 14:29 · Score: 0
  
  Plausible Deniability is bullshit anyway and is just schuck-bait that can have your Mr. Dissident end up diappearing in a torture dungeon because EVERYBODY knows that truecrypt supports those hidden volumes and he has no way to proof that he isn't hiding anymore even if he gives them the main password.
9. Re:TRIM not always good by infinitelink · 2013-12-21 14:58 · Score: 0
  
  He wasn't being disrespectful because he thought my post was technically inaccurate, he was being disrespectful because a lot of people don't like me on slashdot because I have strong opinions and mercilessly club their favorite things
  xD I enjoy your bitchiness, but I'm a wackjob. ;) Keep it up.
  Regards.
  
  --
  Intelligent idiots are we. | Evil men do not understand justice.
10. Re:TRIM not always good by Anonymous Coward · 2013-12-21 15:11 · Score: 0
  
  I modded you down right now, because I hate off-topic posts and stupid drama, not because I hate you (well, I dont hate you either).
11. Re:TRIM not always good by VortexCortex · 2013-12-21 15:18 · Score: 1
  
  I agree and would only like to add that on magnetic media you should use a low level disk maintenance program periodically to reads and writes blocks in place, thus refreshing the signature of the drive. Otherwise I can tell from the error correction frequency of the rotting magnetic bits that you have a "hidden" volume. SSD / flash drives had a similar problem before ware-leveling was common.
12. Re:TRIM not always good by Anonymous Coward · 2013-12-21 15:19 · Score: 0
  
  That is girlintraining's MO. Constantly spouting nonsense on topics he doesn't understand, then starting flamewars when people correct him.
  It is best to just ignore him.
13. Re:TRIM not always good by Jherek+Carnelian · 2013-12-21 15:28 · Score: 1
  
  any opinion I state winds up pissing off some fanboy.
  And the best thing about your posts is that they are never wrong!
  Narcissism FTW!
14. Re:TRIM not always good by fisted · 2013-12-21 15:40 · Score: 3, Insightful
  
  Wow you seem to be one egocentric person.
  
  --
  CLI paste? paste.pr0.tips!
15. Re:TRIM not always good by Khyber · 2013-12-21 16:08 · Score: 1
  
  "You need more training."
  Speak for yourself, failure at cryptoanalysis.
  That's how I break into encrypted crap all the time. SSDs make it much easier to find hidden data.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
16. Re:TRIM not always good by Anonymous Coward · 2013-12-21 16:44 · Score: 0
  
  SSDs and whole disk encryption are certainly an issue. For WDE to work well you need to make an entire partition opaque to outside attackers, so you can't have obviously free sectors on it, lest you narrow the search space for relevant data.
  At any rate, the simplest solution would seem to be for the file system to only trim a certain amount, say perhaps 8GB out of 256GB and leave the rest marked as filled, even when it technically isn't, to preserve as much as possible of the benefits of encryption, while allowing the potential of faster writes. Of course even the pattern of the space that is trimmed might have some value, so care might be required there when considering how to go about it.
  I remember reading at one point the suggestion to leave free space on an SSD with WDE to do the same thing, but I'm not sure that quite works, since how is the drive supposed to know which blocks can be swapped between the partition and the free space if it has no knowledge of the encryption..?
17. Re:TRIM not always good by lilrobbie · 2013-12-21 17:32 · Score: 1
  
  Isn't this one of those situations though where if you are likely to be rubber-hosed, you probably would have compiled the kernel yourself with this type of thing disabled?
  I can't see someone downloading and installing a pre-compiled distro if they are that worried about security....
18. Re:TRIM not always good by darkpixel2k · 2013-12-21 17:34 · Score: 1
  
  That's how I break into encrypted crap all the time.
  The new locks your mom put on the basement door don't count.
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
19. Re: TRIM not always good by Anonymous Coward · 2013-12-21 17:40 · Score: 1
  
  Um, you should get over yourself.
20. Re:TRIM not always good by Khyber · 2013-12-21 18:05 · Score: 1
  
  Trying to insult tends to fall flat when I'm one of the people responsible for your low food prices.
  It's your mother living in my basement, child. She services my husband and myself.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
21. Re:TRIM not always good by darkpixel2k · 2013-12-21 18:06 · Score: 1
  
  Trying to insult tends to fall flat when I'm one of the people responsible for your low food prices.
  Eh? Who are you and how are you responsible for decreasing the price of the food I grow on my farm?
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
22. Re:TRIM not always good by at_slashdot · 2013-12-21 18:33 · Score: 1
  
  Isn't that a configuration that can be changed? That's a default, I assume the "experts" will have no problem to set up their desired behavior.
  
  --
  "It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
23. Re:TRIM not always good by LordLimecat · 2013-12-21 18:42 · Score: 5, Insightful
  
  Dude, youre overstating the threat.
  If the drive is encrypted, theres no more or less threat from brute-forcing.
  From a plausible deniability standpoint, Im not terribly sure how helpful that is ANYWAYS. If someone wants to know if youre using truecrypt, they could, I dont know, look at the MBR and see whether its using the Truecrypt bootloader. The idea that you can say "What partition?" when goons grab your mysteriously unreadable laptop is laughable. Im sure there are super corner cases where that would be helpful, but generally if youre being held by the sorts of people who have the means and ability to do rubber hose cryptography, theyre not going to put up with your BS about "but wait look i gave you a password that boots to an Ubuntu partition which only accounts for 1/2 of the drive's size, and has no data worth encrypting whatsoever!"
  Being involved with multiple organizations which employ encryption for very different reasons, none of them use plausible deniability / hidden encryptions; Id reckon because its not terribly helpful, or even plausible.
24. Re:TRIM not always good by LordLimecat · 2013-12-21 18:44 · Score: 1
  
  You could, I dont know, check the size of the partition on the "plausible" volume he shows you. If drive size is 500GB, and the "plausible" partition is 250, and hes using truecrypt... GEE I WONDER.
25. Re:TRIM not always good by Anonymous Coward · 2013-12-21 18:45 · Score: 0
  
  I see your point. Can this 'feature' be turned off? Even if it can, someone is still tipped off that your unused sectors may not be so unused after all I suppose.
26. Re:TRIM not always good by craighansen · 2013-12-21 19:01 · Score: 2
  
  (1) [Easiest solution] Turn off TRIM usage on encrypted volumes - loss of peak performance, but now you've got your "plausable deniability" back
  (2) [Adequate solution] Fix the firmware so that reading a TRIMed block causes random data to be written to it. However, you had better make sure that exactly the same power usage and timing comes from this activity compared to reading a previously-written block. You had also better be sure that the data is really random, so it can't be distinguished from encrypted data. You must also protect the meta-information as to the number of free and erased blocks.
  (3) [Problematic solution] Do not attempt to simply return psuedo-random data for blocks that have been TRIMed - you must ensure both that additional reads return the same data (such as by seeding the PR generator with the block number) and that performing additional TRIMs on the block cause different data to be returned, so that the ruse cannot be detected by reading the block, performing a TRIM, and reading the block again to see if it's the same. This is actually difficult, as any finite amount of state representing the seed could be detected by multiple TRIM/read cycles, although the effort required grows exponentially with the amount of state used.
27. Re:TRIM not always good by Anonymous Coward · 2013-12-21 21:01 · Score: 0
  
  If the drive is encrypted, theres no more or less threat from brute-forcing.
  Brute-focring? That threat model never changes, that's why the standard of "broken crypto" is an attack more efficient than bruteforcing. So of course there's no more or less threat from it. However, if you're saying that this doesn't make your data any more or less secure, you're wrong about that. If you read the links I provided, they detail how this provides a means of finding leaked data, such as the filesystem you're using. This could be useful for known plaintext attacks (of which there really aren't any for AES afaik, but saying that this doesn't weaken the security is plain wrong). There's also (as of now unpublished, afaik) reasearch I know of where you can use where (and when, depending on the attack) data was written to disk to narrow down the possible contents. It's pretty well established that any leak of information is bad news, cryptographically.
  
  From a plausible deniability standpoint, Im not terribly sure how helpful that is ANYWAYS.
  
  Like I said, niether are the cryptsetup team, that's why they don't provide support for creating hidden volumes.
  
  If someone wants to know if youre using truecrypt, they could, I dont know, look at the MBR and see whether its using the Truecrypt bootloader. The idea that you can say "What partition?" when goons grab your mysteriously unreadable laptop is laughable.
  I don't think you understand hidden volumes. The idea is that there's an outer encrypted volume, which you disclose, and then hidden in the slack space of that volume, another encrypted volume exists. The point of that being, when coersive measures are in play, only the outer volume is divulged. There is nothing particularly special about the slack space of the hidden volume, it looks just like actual unused space interspersed with the used space on a used volume (this is where the cryptsetup team disagrees, as the method TC uses to accomplish this is... less than graceful).
  
  Im sure there are super corner cases where that would be helpful, but generally if youre being held by the sorts of people who have the means and ability to do rubber hose cryptography, theyre not going to put up with your BS about "but wait look i gave you a password that boots to an Ubuntu partition which only accounts for 1/2 of the drive's size, and has no data worth encrypting whatsoever!"
  Now this leads me to believe you do understand, despite the fact it directly contradicts your earlier statement. In any case: Hidden volumes are supposed to provide plausible deniability, the key word there being plausible. If you see someone with a half full hard drive, your first thought isn't "there's a hidden volume." My primary drive is far, far less than half full (I use a dedicated SSD for my root partition, wheras most of my actual data is stored in my /home drive). Can a coersive actor continue to use rubber hose methods to force you to divulge a hidden partition? I suppose, but they sure as hell can't in any jurisdiction where "innocent until proven guilty" still has any say, and they'd basically end up torturing me to death I guess.
  
  Being involved with multiple organizations which employ encryption for very different reasons, none of them use plausible deniability / hidden encryptions; Id reckon because its not terribly helpful, or even plausible.
  Then your threat model is clearly different from those who do need it, so I'm not sure how that applies then. For example, if Greenwald's partner had a hidden volume on the siezed drive (and it's entirely possible he did), it easily could have bought him the time needed to force his detaining into the maximum time limit.
28. Re:TRIM not always good by Anonymous Coward · 2013-12-21 21:03 · Score: 0
  
  The outer parttition could be all 500GB and the hidden partition could still be 250GB. The relationship between hidden and outer is that of nested partitions, not contiguous partitions. The hidden partition is stored in the slackspace of the filesystem, not the drive.
29. Re:TRIM not always good by SlashRAH · 2013-12-21 22:39 · Score: 1
  
  By default, LUKS ignores (errors, actually) those discard/TRIM messages at the block device layer, preventing the SSD from processing them. You have to explicitly override this in order to TRIM a block device under an encrypted filesystem, in which case you're on your own.
30. Re:TRIM not always good by thegarbz · 2013-12-22 01:04 · Score: 1
  
  Truecrypt files instead of partitions?
  Wouldn't that counter the issue of TRIMing? If the Truecrypt volume is created of a fixed size it won't get TRIMed by the OS. You can then have anything you want in that partition including a shadow volume, and in this scenario there's nothing to indicate that the shadow exists saving you at least one rubberhosing.
31. Re:TRIM not always good by Anonymous Coward · 2013-12-22 01:38 · Score: 0
  
  Just because you managed to put "cryptanalysis" and "plausible deniability" in the same sentence doesn't mean you know what you're talking about. Just FYI. The sentence is grammatically correct though.
32. Re:TRIM not always good by Khyber · 2013-12-22 03:48 · Score: 2
  
  Your method of cultivation is likely wasteful, polluting, and irresponsible.
  I can do it at 10% of the price you do, using 1/8 the land area, consuming between 60-90% less water, and a ~50% reduction in required fertilizers. Because it's in a much smaller area, the requirement of machines for harvesting is gone. My production buildings can be entirely solar-powered, as well.
  Morocco, Australia, China, UK, Japan, USA, Brazil, all utilize my technology.
  Your seed stock, if not from Monsanto, or produced yourself, likely came from a building utilizing my technologies.
  Been on the BBC for the same tech.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
33. Re:TRIM not always good by Anonymous Coward · 2013-12-22 04:01 · Score: 0
  
  Yes, it will TRIM it. That's the entire point of TRIM. The idea being that you can't write to an SSD without the block being Free first, so with TRIM it just does it as soon as it can (the other method being you free it when you need it). It's not the partition that activates TRIM, it's the filesystem.
34. Re:TRIM not always good by darkpixel2k · 2013-12-22 05:52 · Score: 1
  
  Your method of cultivation is likely wasteful, polluting, and irresponsible.
  How so? I own my land, I till my land, I plant on my land, and it feeds my family and there's usually enough to feed other families as well.
  
  I can do it at 10% of the price you do, using 1/8 the land area, consuming between 60-90% less water, and a ~50% reduction in required fertilizers.
  I use cow manure from a local auction house and no pesticides along with rainwater and water from my pond.
  
  Because it's in a much smaller area, the requirement of machines for harvesting is gone.
  Other than the rototiller and the pickup tuck I use to haul the manure, everything else is done by hand or with hand tools like a shovel and hoe
  
  My production buildings can be entirely solar-powered, as well.
  It's called a greenhouse. We're setting one up this spring.
  
  Morocco, Australia, China, UK, Japan, USA, Brazil, all utilize my technology.
  You invented the sun and rain?
  
  Your seed stock, if not from Monsanto, or produced yourself, likely came from a building utilizing my technologies.
  We try to avoid seeds from big commercial outfits, and try to buy as much from other local farmers as well.
  
  Been on the BBC for the same tech.
  Meh. What does any of this have to do with me joking about the locks on your mom's basement?
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
35. Re:TRIM not always good by glassware · 2013-12-22 06:15 · Score: 1
  
  This kind of automatic naysaying because of a rare use case is why awesome projects don't move forward. The most vocal objections to progress come from people who rely on an unintended side effect of the interaction between complex pieces of software.
  Oh, wait, I forgot. "Terrible news" means "I might actually have to remember to disable TRIM support if I A) buy an SSD, B) use TrueCrypt, and C) rely on shadow volume support."
  If you, or anyone, is relying on the plausible deniability feature of truecrypt enough for its failure to be terrible news, I would think you would remember to check whether TRIM was enabled or not before using it.
  Heck, maybe even TrueCrypt could write a test to see if TRIM was enabled before allowing you to create a shadow volume. That might be a really useful feature.
36. Re:TRIM not always good by Anonymous Coward · 2013-12-22 10:05 · Score: 0
  
  Make the outer volume the same size as the disk? Full disk encryption? Stop being limited in the scope of your ideas, for most people this is a boon.
37. Re:TRIM not always good by Khyber · 2013-12-22 12:41 · Score: 2
  
  Your joke was pretty poor, and your arguments equally weak. Soil based farming is wasteful. It's proven. It is resource-intensive and uses more than what is truly needed. You're wasting your own resources and wallowing in your ignorance.
  Your 'it's called a greenhouse' quip is out of line, too. We make things grow without light - http://www.youtube.com/watch?v=9ZTikdxj8AI and that tech has recently been expanded into growing lettuces herbs, and more (and not typical lightless crops.)
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
38. Re:TRIM not always good by darkpixel2k · 2013-12-22 14:26 · Score: 1
  
  Your joke was pretty poor, and your arguments equally weak. Soil based farming is wasteful. It's proven. It is resource-intensive and uses more than what is truly needed. You're wasting your own resources and wallowing in your ignorance.
  Your vague allusions about being better than me because you know some magical farming technology are pretty tiresome. Funny how you never mention what they are so anyone reading your comments can prove that you're 'superior'. My guess is you have no clue what you're talking about.
  
  Your 'it's called a greenhouse' quip is out of line, too.
  It's slashdot dude. Don't take everything you read here too seriously.
  
  We make things grow without light - http://www.youtube.com/watch?v=9ZTikdxj8AI and that tech has recently been expanded into growing lettuces herbs, and more (and not typical lightless crops.)
  Oh thank God I finally have a solution! All that sunlight that I was using up for my plants! I've heard rumors that due to my wasteful sunlight farming parts of Alaska actually have little or no sun for 6 months out of the year!!!11one1
  
  We're saved. All thanks to some dude posting on slashdot... (Don't take those comments too seriously either.)
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
39. Re:TRIM not always good by LordLimecat · 2013-12-22 19:00 · Score: 1
  
  If knowing how to construct a stream of contiguous, encrypted data helps you to break it easier than when it was scrambled / fragmented encrypted data, then your encryption is fundamentally broken, and turning TRIM off wont change that fact.
  Otherwise there would be an option in truecrypt "please fragment my data as much as possible to make the encryption stronger".
  Your links consist of truecrypt devs saying "it could be used for further analysis" without explaining what is meant by that, and some guy's random blog from 2011. Find an article from dm-crypt / truecrypt devs laying out a plausible attack, or something from a respected crypto expert (like Bruce Schneier), otherwise Im not buying it.
40. Re:TRIM not always good by Anonymous Coward · 2013-12-22 21:30 · Score: 0
  
  some guy's random blog from 2011
  That's a (and arguably the) lead dev for dm-crypt/LUKS/cryptsetup [1], and the post was quoted as it's what cryptsetup (i.e. LUKS) links to in the release notes to explain why you should be careful if you're enabling TRIM [2]. And he DID lay out a plausible attack, he explicitly showed you can determine the filesystem. I'm not sure how else to convince you that data is being leaked, you're being kind of bullheaded in the direct face of evidence.
  [1] https://code.google.com/p/cryptsetup/source/browse/
  [2] https://code.google.com/p/cryptsetup/wiki/Cryptsetup140
41. Re:TRIM not always good by Anonymous Coward · 2013-12-22 21:41 · Score: 0
  
  If knowing how to construct a stream of contiguous, encrypted data helps you to break it easier than when it was scrambled / fragmented encrypted data, then your encryption is fundamentally broken, and turning TRIM off wont change that fact.
  Oh, and I guess i should explain that no, that's not how it works. In the simplest form, let's say that the attacker wants to know if you're storing movies or text documents. Well, movies are more likely to be written in large, continuous chunks than text documents are.
42. Re:TRIM not always good by Anonymous Coward · 2013-12-22 23:46 · Score: 0
  
  Which is exactly what someone relying on hidden volumns would say.
43. Re:TRIM not always good by LordLimecat · 2013-12-23 05:06 · Score: 1
  
  But he didnt lay out a plausible attack. He indicated that an attacker could determine your filesystem based on sector useage, but thats it. Telling how the encrypted data is laid out shouldnt help you; even if you could grab the sectors containing individual files (which should not be possible), you STILL wouldnt be any closer to breaking the encryption-- if you were, the encryption is already flawed.
  What hes basically saying is that the encryption is not secret and your OS / FS may be identifiable, even if the actual data is encrypted. Thats not terribly shocking, since you could already generally tell what OS is using a particular WDE if youre using truecrypt or dm-crypt (since one is windows-only, and one is linux only, and both have identifiable bootloaders). Heck, if youre using truecrypt for WDE, the whole world ALREADY knows your filesystem: in-place encryption requires NTFS, and you cant use truecrypt WDE with anything but Windows >= XP && Windows 8. That in no way weakens the encryption.
  You and he are both correct to point out to a potential encryptee (is that a word?) that TRIM does have implications for plausible deniability. Im saying that other than in crypto-geek fantasies, plausible deniability seems incredibly un-useful when your adversary is already 100% sure you're using encryption in the first place (a trivial look at the bootloader would tell them that).
44. Re:TRIM not always good by Khyber · 2013-12-23 11:03 · Score: 0
  
  "Your vague allusions about being better than me"
  Oh, look, more ignorance attributing something to something I never implied, alluded to, or hinted at.
  Trust me, if I thought I was better than you, I'd have told you right to your face.
  "Don't take everything you read here too seriously."
  When you're telling outright falsehoods, you'd better be prepared to get taken to task for it. I notice you still can't come up with any counter-argument that has any rational factual basis, which is why you're trying to play the 'save face by making insults' game.
  "Oh thank God I finally have a solution! All that sunlight that I was using up for my plants! I've heard rumors that due to my wasteful sunlight farming parts of Alaska actually have little or no sun for 6 months out of the year!!!11one1"
  Now your sarcasm makes you look like a typical asshole with a lacking education.
  "We're saved. All thanks to some dude posting on slashdot..."
  Or you're screwed. I decide to hand this tech over to China, America's Ag. economy dies as it can no longer compete.
  I'm not better than you, just smarter, more intelligent, and more driven.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
45. Re:TRIM not always good by Anonymous Coward · 2013-12-23 15:42 · Score: 0
  
  Again, you don't seem to understand how hidden volumes work nor the threat models they address, nor the point of encryption. I'm not going to repeat myself, just re-read my posts.
46. Re:TRIM not always good by darkpixel2k · 2013-12-26 04:32 · Score: 1
  
  "Don't take everything you read here too seriously."
  When you're telling outright falsehoods, you'd better be prepared to get taken to task for it.
  Like I said before, the thing about your mom changing the basement door locks was a joke. You're the one who went off into the woods talking about how your farming was superior or some such crap.
  
  I notice you still can't come up with any counter-argument that has any rational factual basis, which is why you're trying to play the 'save face by making insults' game.
  I'm not trying to save face. Like I said before, I made a joke. You thought it was in poor taste, and then started talking about farming. Everyone has their own sense of humor.
  
  "Oh thank God I finally have a solution! All that sunlight that I was using up for my plants! I've heard rumors that due to my wasteful sunlight farming parts of Alaska actually have little or no sun for 6 months out of the year!!!11one1"
  Now your sarcasm makes you look like a typical asshole with a lacking education.
  "We're saved. All thanks to some dude posting on slashdot..."
  Or you're screwed. I decide to hand this tech over to China, America's Ag. economy dies as it can no longer compete.
  All of which I find irrelevant. I don't care what China does--short of landing on my doorstep with guns. I farm for my family and friends. Why do I need to invest in your solution for that? I'm sure it makes sense to large commercial growers, just not a small-time 'hobby' farmer in the middle of nowhere.
  
  I'm not better than you, just smarter, more intelligent, and more driven.
  Possibly. I am arguing with a troll on slashdot...
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
Your other fun by tepples · 2013-12-21 12:43 · Score: 2

The fun in having a distribution automatically do the right thing is that you get to a working system faster, so that you can get to your other fun faster, whether you prefer casual, hardcore, or Dwarf Fortress.
TRIM? who needs it! by sshir · 2013-12-21 12:52 · Score: 3, Insightful

Well, if you don't do random writes, you don't need TRIM.

How to get away from random writes you ask? Simple! Just use BTRFS.

"But my database!" you say. Well, the answer is simple - time to move away from 50 year old technology and to a modern database engine, the kind that doesn't do random writes either (fractal tree based, for example).

Disclaimer: All of the above is not written for stodgy "enterprise level" types.
1. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 12:58 · Score: 0, Troll
  
  Yea it's written for braindead dot com wannabes who think hip barely usable technology is the meaning of life, and wonder why their shit products are unreliable.
2. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 13:05 · Score: 0
  
  What happens when your free space gets used up?
3. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 13:11 · Score: 0
  
  Let the parent post be a lesson to everyone: never go full retard.
4. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 14:50 · Score: 2, Funny
  
  partition Czechoslovakia
5. Re:TRIM? who needs it! by fisted · 2013-12-21 15:53 · Score: 1
  
  then you balance it it (never mind the occasional data loss, we have more than enough data anyway)!
  i hear balance is the ultimate solution for any btrfs problem.
  
  ran out of free space? balance it!
  bad filesystem corruption after power loss? balance it!
  faulty blocks? balance it!
  tree not balanced? balance it!
  neighbor's dog taking a dump on your lawn? get the hell off m^W^W^W^W^W balance it!
  
  i think you kind of get the idea
  
  --
  CLI paste? paste.pr0.tips!
6. Re:TRIM? who needs it! by fnj · 2013-12-21 17:00 · Score: 1
  
  How to get away from random writes you ask? Simple! Just use BTRFS.
  Or you could use ZFS, which is an actual mature and reliable system which uses COW.
7. Re:TRIM? who needs it! by sshir · 2013-12-21 17:16 · Score: 1
  
  Sure, ZFS is alright too, but where's the excitement in that? :)
8. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 17:37 · Score: 0
  
  Yea it's written for braindead dot com wannabes who think hip barely usable technology is the meaning of life, and wonder why their shit products are unreliable.
  Yeah, because an ancient rotting codebase running a database engine from last decade has pushed Slashdot to the top Silicon Valley's "What's Hot" list...
9. Re:TRIM? who needs it! by TheDauthi · 2013-12-21 17:42 · Score: 2
  
  Excitement is a bug - not a feature - in a filesystem.
10. Re:TRIM? who needs it! by LordLimecat · 2013-12-21 18:48 · Score: 2
  
  Im not entirely sure you understand what TRIM does. Its not to get rid of random writes, its to deal with a scenario where you have written and deleted 120GB from a 120GB SSD. Your OS has marked 120GB as "deleted", but those blocks are still occupied and cannot be re-written until they are first erased. This incurs a penalty, particularly since the erase block size is typically larger than the FS cluster size.
11. Re:TRIM? who needs it! by jones_supa · 2013-12-21 19:26 · Score: 1
  
  That is not completely accurate either. The main purpose of TRIM is to inform the disk which areas are not used by the file system so that they can be safely overwritten by remapped data for wear leveling purposes.
12. Re:TRIM? who needs it! by LordLimecat · 2013-12-21 19:58 · Score: 2
  
  That is not correct: its not about doing anything safely or even about wear-leveling. The filesystem is what handles writes, and it knows where is safe to write to, and wear-leveling is helped by TRIM but that is not what TRIM actually does.
  TRIM simply informs the drive that it can perform an erase on a particular block when the filesystem marks it as deleted. This is so that any erases or remapping that needs to happen can e done when the drive is idle-- basically, it triggers garbage collection. With TRIM and auto-garbage collection off, the drive into a brick wall when it needs to write 10GB of data and it turns out that there are no already blanked blocks available; in that case it would have to do read-erase-writes for 10GB or more (due to amplification) worth of blocks, slowing everything to a relative crawl.
  Just about everything an SSD does is improved by garbage collection, and TRIM is just OS- / FS- triggered garbage collection.
13. Re:TRIM? who needs it! by Anonymous Coward · 2013-12-21 20:39 · Score: 0
  
  That is not completely accurate either. The main purpose of TRIM is to inform the disk which areas are not used by the file system so that they can be safely overwritten by remapped data for wear leveling purposes.
  Why do you call it the main purpose, you don't get wear leveling without also fixing the performance problem, but you can get write performance without doing wear leveling if you wanted, and do wear leveling in the filesystem or something.
  Why would anyone even CARE if their SSD had horribly degraded write performance.. but you could use it longer that way by fucking with your OS to send additional IO commands... Whoopedeedooo...
14. Re:TRIM? who needs it! by sshir · 2013-12-22 00:53 · Score: 1
  
  I tend to write a lot between the lines. Here's the one of the lines I skipped: in COW setups, in stable state you write at exactly same rate as you free blocks. I.e. by writing 1 gig, you're freeing 1 gig. And so on to the end of block space, then you wrap and repeat. Wear leveling is additional side effect.
15. Re:TRIM? who needs it! by Rockoon · 2013-12-22 01:52 · Score: 2
  
  sigh this isnt exactly right either
  
  The situation is thus:
  
  An SSD is a physical storage that presents a logical drive to the system. There is no 1:1 mapping between physical sectors and logical sectors. Logical sector 0 is always the boot sector, but can be located anywhere on the physical media.
  
  An SSD is also unaware of the file system that is present. Prior to TRIM the entire logical volume, including all of its free sectors, were always allocated to physical locations and the SSD was unaware of which physical/logic blocks were considered free by the filesystem. This meant that the SSD could never treat the logical blocks allocated by the volume (but were considered free by the filesystem) for any purpose other that storing data. For all intents and purposes, the filesystems 'free' blocks were indistinguishable from valid data that needed to be protected.
  
  Thus begat the rise of over-provisioning. Thats 120GB SSD was probably a 128GB SSD pretending to only be able to store 120GB, leaving 8GB as a pool of 'ready to be written to' blocks of data.
  
  However as TRIM support began ramping up, it was now possible for the filesystem to inform the SSD that some of the logical volume was unimportant and could also be used as a pool of 'ready to be written to' blocks of data. Thus begat the rise of power-of-two SSD's whos performance didnt rapidly begin to suck.
  
  Over-provisioning is still recommended if there is any chance of nearly filling the SSD, but is now completely irrelevant in the case of sparsely populated logical volumes. So now modern SSD's also have a configurable amount of over-provisioning with (typically) a quite small amount of default over-provisioning.
  
  TL;DR: Without TRIM, the SSD must consider your entire logical partition (free space and all) as valid data that needs to be maintained. With TRIM, the SSD can be informed as to which space is free, thus it does not need to maintain the integrity of the data that is there.
  
  --
  "His name was James Damore."
wTF Windows 7 had this 4 years ago by Billly+Gates · 2013-12-21 13:07 · Score: 1

And supports vectors of ranges to Trim. Does it support this spec yet?
Come on.

--
http://saveie6.com/
So you build gamer boxes by Anonymous Coward · 2013-12-21 14:00 · Score: 0

So you build gamer boxes then. I imagine sales have tanked pretty good of late.
Good News for Mint Enthusiasts by ohnocitizen · 2013-12-21 14:09 · Score: 0

Is it bad that my first thought when reading this was "cool, when will Mint get this"?
1. Re:Good News for Mint Enthusiasts by Anonymous Coward · 2013-12-21 14:41 · Score: 0
  
  and 5 years ago the sentiment was "cool, when will Ubuntu get this"?
2. Re:Good News for Mint Enthusiasts by fisted · 2013-12-21 15:56 · Score: 0
  
  this is about a default setting, you ignorant fuck.
  
  --
  CLI paste? paste.pr0.tips!
3. Re:Good News for Mint Enthusiasts by ohnocitizen · 2013-12-21 18:28 · Score: 0
  
  Ah, the famously friendly linux community! Hahahaha seriously though, if someone doesn't know something and you do, it doesn't hurt to be friendly about it :)
4. Re:Good News for Mint Enthusiasts by fisted · 2013-12-22 05:54 · Score: 1
  
  Huh? You would have obtained that knowledge from merely reading TFS, not even TFA, so all you're doing now is further demonstrating your stupidity.
  
  That being said, I run {Free,Net}BSD, so your point about the linux community is moot.
  
  Protip (even applies to both, linux and BSD communities): It's only you lazy fucks who we're not friendly with.
  
  --
  CLI paste? paste.pr0.tips!
5. Re:Good News for Mint Enthusiasts by ohnocitizen · 2013-12-22 08:47 · Score: 1
  
  It amazes me that I'd get dinged with mod points over calling you out in a polite fashion. What awful butthurt to live with, that you feel the need to be so vulgar. Your pro-tip is one I happily ignore. I'm polite with people even to the extent of not automatically assuming laziness, or considering not knowing a given fact a sin.
6. Re:Good News for Mint Enthusiasts by fisted · 2013-12-22 10:20 · Score: 1
  
  As said, you're being lazy for not having read TFS. That isn't a wild assumption, your post makes that clear
  
  --
  CLI paste? paste.pr0.tips!
Re: "Good news for hardware enthusiasts!" by TheGrimmReaper · 2013-12-21 14:25 · Score: 1

What does desktop vs. laptop have to do with it? Plenty of people use SSD's in desktops (I sure do)
Out-of-the-box? by rossdee · 2013-12-21 15:16 · Score: 4, Informative

Does Linux come in a box these days, I thought you just downloaded it, and didn't have to pay for it and the packaging...
1. Re:Out-of-the-box? by jones_supa · 2013-12-21 15:43 · Score: 0
  
  If you paid for it, the full SSD support would have been in place at the same time the first drives rolled out to the market.
2. Re:Out-of-the-box? by SeaFox · 2013-12-21 18:39 · Score: 1
  
  I find the term "out-of-the-box" much preferable to "baked-in", which they are even using to describe built-in features on software nowadays.
3. Re:Out-of-the-box? by Anonymous Coward · 2013-12-21 21:58 · Score: 0
  
  Boxed version come with a zealot's handbook, 8x10 autographed picture of Linux Torvalds, and a bag of toejam hand picked from Richard Stallman's feet.
4. Re:Out-of-the-box? by fph+il+quozientatore · 2013-12-21 22:25 · Score: 1
  
  Sure, it will come in a box, as did the previous stable version.
  
  --
  My first program:
  Hell Segmentation fault
Re:The Crumbling Kingdom of Buntu by fisted · 2013-12-21 15:47 · Score: 1

Why is this modded down? It isn't even bad advice.

--
CLI paste? paste.pr0.tips!
Done for a while by Anonymous Coward · 2013-12-21 19:05 · Score: 0

I had a disk die a few years ago, and replaced it with an SSD. The guy in the store was a windblows guy: "Too bad Linux doesn't support trim". I bought the SSD, and ...Linux has been supporting trim for years. I add discard when installing new systems. It would be nice out of the box, but it only takes about 30 seconds to add the word 'trim' to fstab. I also get new microcode from Intel and get it loading in /etc/init.d/rc.local. Again, its a 30 second thing that brings the processor up to date. I don't know why the windblows people are yelping that 'Linux is behind' when it comes to file systems. I've been using Linux since 1994, and all my file systems have been self cleaning. I remember seeing hundreds of forums even up to the early 2000's windows users telling each other to 'remember to defrag your hard drive'. WTF? Didn't IBM create self-cleaning file systems in 1967? Linux has had it since (at least) 1994, the windblows folk (apparently) got it sometime after 2000.
1. Re:Done for a while by Anonymous Coward · 2013-12-22 02:30 · Score: 0
  
  LOL.."Windblows". Hilarious.
Ubuntu != Linux by Anonymous Coward · 2013-12-21 19:45 · Score: 4, Informative

It's been in the kernel for a long time now, google tells me since 2.6.33 (Which was released early 2010, about a half a year after Windows 7 was released). Ubuntu 12.04 (The last LTS) shipped with 3.2, so you could already enable TRIM using 12.04. This announcement is nothing more then a default settings change, I have no idea why it's even a big deal (Or why this wasn't already the default, I've been using it for a while now).
I recently Trimmed by danknight48 · 2013-12-21 20:50 · Score: 0, Offtopic

Me and misses did the monthly LTS trim of our immediate bush gardens. Performance hasnt really improved, and, stability cums and goes. This is a known issues when running a bloated OS like Ubuntu on critical hardware systems.
We recently made a switch to a pure Debian based bush garden, the performance is superb. Too bad its over within a second or two.
Get in there! Pre Xmas drink banter!
Re:The Crumbling Kingdom of Buntu by Anonymous Coward · 2013-12-21 21:01 · Score: 0

It was modded down simply because the poster had the temerity to say something against the great god Canonical.
Personally, I gave up on *buntu around the 10/10 release and moved to two distros. CentOS for my servers and main laptop and Fedora for my play machine. Now I have stable systems. Yes, I could have got that with Debian. I started using Linux with Debian more than 10 years ago but got seduced by the Ubuntu spells. I went to a RH based distro simply because my employers are replacing their Windows 2003 servers with RHEL. No we don't use Sharepoint, IIS or any other MS crapware but software from the likes of Oracle and IBM.
I don't regret moving to CentOS. It is really stable and (currently) has the advantage of still using Gnome2. Yay!
Canonical has IMHO lost the plot.
Are Chinese knock-offs considered bloated? by Anonymous Coward · 2013-12-22 01:24 · Score: 0

This is a known issues when running a bloated OS like Ubuntu on critical hardware systems.
Wondering here about Red Flag and Unix of the Forbidden City...
Simplicity? by Anonymous Coward · 2013-12-22 03:30 · Score: 0

I'm currently using LVM snapshots for upgrades and backups -- what am I missing compared file system snapshots?
Seriously dude. I use LVM a lot and am familiar with the commands and operations. But, fuck it's complicated and I still have zero faith in it. Every time I perform a relatively major(in my mind) action like expanding a volume, I quiver with anticipation of losing the whole volume and all its data.
It shouldn't be so complicated that I'm afraid to add disk space. When I add space to VMWare or my SANs, it's click click and no fear. Then I turn to LVM and piss. Even Acronis, after years, can't properly figure out and handle LVMs, falling back to block mode.
Then there is the whole issue of recovering a failed or damaged LVM.
1. Re:Simplicity? by profplump · 2013-12-22 12:30 · Score: 2
  
  I don't understand what's scarier about this:
  lvextend -L+6G /dev/foo/bar
  than this:
  vmkfstools -X 6G /vmfs/volumes/foo/bar.vmdk
  But that wasn't really the the question I was asking -- what's the different between file-system snapshots and LVM-snapshots (other than filesystem-snapshots obviously don't allow changes to the filesystem itself, which most people don't care about most of the time). Is there something that makes tasks like backups or upgrades easier or faster? Is there some other task I'd snapshot for that just isn't possible with LVM?
  There are lots of reasons to like newer filesystems, but the +4 poster above specifically said the LVM snapshots were not as useful as filesystem snapshots, and I'm just wondering what I'm missing.