I still have two or three recent (i.e. last four or five years) devices that have problems seeking VBR files or displaying the proper duration.
Even foobar2000 has issues with seeking in MP3s. From the FAQ:
Why is seeking so slow while playing MP3 files?
The MP3 format doesn't natively support sample-accurate seeking, and sample accurate seeking is absolutely required by some features of foobar2000 (such as.CUE playback). MP3 seeking can't be optimized neither for CBR files (frame sizes aren't really constant because of padding used), nor for VBR files (both Xing and VBRI headers in those files contain only approximated info and are useless for sample-exact seeking). Therefore MP3 seeking works by bruteforce-walking the MPEG stream chain and is appropriately slow (this gets faster when you pass through the same point of file for the second time because seektables have been built in the RAM).
You need weird-ass buggy fb2k plugins, but are only missing format support in WMP? Do you play a lot of ancient tracker music or something?
If you find the fb2k interface so intimidating perhaps you'd be better off with its much simpler cousin, Boom. Not sure if it's got much support for particularly oddball media formats though.
Multi-process architecture... I've not really noticed a problem with the threaded one, and Firefox already sticks flash objects in a separate process. So what's the real draw
Isolation. The same reason you want different apps to have their own processes instead of having the whole of userspace in one big blob. You can give processes reduced privileges to reduce the scope of exploits, hangs and crashes don't take down more than they have to, and leaks don't force you to restart the entire system to recover resources.
Plus it makes for simpler concurrency. Kind of handy when you've got a stop-the-world garbage collector if you can just split the world into many smaller independent units, each able to run at the same time and each with an order of magnitude less work to do and no synchronisation to worry about.
64bit... again, bragging points about how many bits you use, no functional difference to anyone
ASLR is a fuckload more effective when it has a reasonably sized address space to work with, and 2^32 is miles away from being reasonable. It's the difference between an attacker having to guess one of 8 locations and one of 8 billion. Plus, memory mapping things is awesome, and also a fuckload easier with a reasonably sized address space.
And hey, some of us actually use our browsers quite a lot. Mine's eating 5.5G right now. So many windows and tabs, and absolutely no fucking reason whatsoever why that should be considered even slightly unreasonable.
How many people do per-user salting of the password hash?
People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.
If you're using passwords for authentication in your app, use a recognised key derivation function. Use PBKDF2 or bcrypt and tune them to take at least 100ms to run. If you're extra paranoid, use scrypt and tune it to take 100ms and 16MB of memory. If you're doing anything else without having a well-received peer reviewed academic paper describing it, you might want to reconsider.
FreeBSD uses rcNG, acquired from NetBSD (basically shell scripts and a binary for resolving dependency order defined in magic comments), on top of a simple BSD-style init. There's some vague movement towards porting launchd, but I don't think anyone's holding their breath.
pkgng's made port upgrading much less burdensome - even fairly complex dependency changes can be handled automatically as of 1.3, and the official package repositories are a lot more useful now. They even have stable security-fix-only branches.
I still make my own customised builds, but I make binary packages in an isolated jail using poudriere. 99% of upgrades are a matter of updating its ports tree, running rebuild-packages, and running pkg upgrade on all my machines.
You couldn't pay me to go back to portupgrade/portmaster/portmanager.
Not really - ports doesn't even have a *concept* of upgrading, it's just uninstall/reinstall and hope you can work out how to handle all the dependencies. This is why FreeBSD's got so many tools for managing them - portupgrade, portmanager, portmaster, all with their own little and not so little quirks.
We do have an apt-alike these days, in the form of pkgng. pkgsrc also has pkgin.
It's stable enough for general use, but maturity counts for a lot with filesystems, especially when they're as complex as ZFS. It's also a third-party add-on rather than an official part of the OS which does raise some issues.
Conversely it's practically the default on FreeBSD, and it's been available since 2008.
pkgng's still missing the ability to track certain changes automatically, so you occasionally have to force-remove a package or manually change an origin as per/usr/ports/UPDATING. I think they're expecting to resolve that in 1.3 fairly soon.
I've been using it for about 18 months across a small group of machines with about 1400 packages between them, and it's pretty much entirely demolished any apt-envy I've had.
You can also track the changes in a somewhat friendlier format using FreshBSD. Full commit messages (up to a point) upfront, more useful Atom feed, breakdown by committer etc.
Reality disagrees with you. The user data portion of a sector is normally a power of two for convenience, being used on computers with power of two page sizes, but drives themselves are no more limited to power of two number of or size of sectors than your computer is limited to power of two size array or structure lengths, and this is readily confirmed by the existence of disks with 520 byte sectors (and somewhat different physical sizes) and an irritatingly diverse range of sector counts.
Hard disk drives use sectors which at some basic level have to be addressed by a powers of two binary addressing system. This means that no matter what else you do with sector sizes or block sizes, the binary counting system *always* comes into the picture.
Right, they're addressed using LBA48, which happens to be encoded in binary because that's how we build computers. That doesn't imply disks naturally only support powers of two for sector counts or sizes - they evidently don't.
CDs and DVDs have 2,352 and 2,418 byte physical sectors. Some Fibre Channel HD's support 520 byte sectors, and of course like optical discs all HD's have substantially bigger physical sectors internally for error detection and correction. A quick sampling of some of my HD's reveals drives with 732,566,646, 3,907,029,168, 500,118,192 and 312,581,808 sectors (at least they're all even?).
Ethernet is even more flexible, supporting any frame sizes between 64 bytes to over 9KB, hardware permitting. Note 9KB is not a power of two.
Wrong, and wrong again. *All* computer peripherals transmit data to and from computers encoded in binary signals. It means that all computer based addressing is essentially binary
Um. Yes, the numbers are encoded in binary. No, this doesn't mean computers can only handle number maximums that are a power of two. Memory happens to be like that because it has to be insanely low latency and simple bit operations like masking off the lower portion of an address is very efficient, but not everything is so restricted.
Why always picking on the HD manufacturers? Your GigE network runs at 1,000,000,000 bits per second, not 1,073,741,824, what a scam!
Memory is measured in multiples of powers of two because that's how the addressing works. Disks and network have no such fundamental limitations - they count in sectors and frames, which are themselves not necessarily powers of two.
It'll perform a bit worse than a GTX Titan, which gets in the region of 330Mhash/sec. For comparison, an AMD HD5870 from 2009 managed about 400Mhash/sec.
8GB isn't hefty by any stretch of the imagination, especially not when you're messing with dedup. For decent performance the recommendation is somewhere along the lines of 20-30GB per TB, though you can mitigate that somewhat by using an SSD for L2ARC.
The transaction limits on unverified payments are pretty small (£15 here in the UK, recently raised from £10), and you'd expect any such system to be wary of lots and lots of them.
The lack of signature and PIN verification also means any liability for losses through such a system rests on the bank, not you, provided you report the loss of your card in good time. Same should apply if someone manages to exploit such a feature while you still have your card, provided you dispute the payments not too long after receiving your statement.
Right, and it's less likely to die from shock or head crash or manufacturing defect, and when it runs out of erase cycles it fails soft; writes fail, but it's still readable; certainly a better failure mode than most drives. Yes, the X25-M has a 5 year design life, just as platter based drives, but I suspect it's also more likely to actually achieve it, firmware update screwups aside.
I would expect they'd be using some sort of slot, something like this. Motherboard manufacturers aren't exactly going to be thrilled at the idea of putting some yet more expensive components on there, but they might be happy to hook up a small ZIF socket thing like some of them do with CF.
Intel actually had some weird ZIF connected SSD's on there a while ago on preorder, but they appear to have disappeared.
Either way, it's nice to see some hybrid storage stuff which isn't ZFS L2ARC (zpool add tank cache/dev/my_ssd -> tank now has an 80GB SSD for fs cache). Kind of surprised it hasn't been done in software elsewhere really; you'd think there would be some Linux developer who found the idea compelling, or even Microsoft wanting to extend ReadyBoost to its logical conclusion.
I've tried an X25-M on a few servers with LSI SAS controllers (as used by PERC 6i, though I don't think I've used that exact chip) and been disappointed to encounter IO hangs and other drives disappearing randomly; even just having an X25-M plugged in is enough to seemingly make the controller rather unhappy. Doesn't appear to be a driver problem, unless it's one shared by FreeBSD, Linux and Solaris.
Hopefully Intel will do an SAS version at some point; they could compete against 15kRPM drives rather well, I think.
Slashdot Mirror
I still have two or three recent (i.e. last four or five years) devices that have problems seeking VBR files or displaying the proper duration.
Even foobar2000 has issues with seeking in MP3s. From the FAQ:
Why is seeking so slow while playing MP3 files?
The MP3 format doesn't natively support sample-accurate seeking, and sample accurate seeking is absolutely required by some features of foobar2000 (such as .CUE playback). MP3 seeking can't be optimized neither for CBR files (frame sizes aren't really constant because of padding used), nor for VBR files (both Xing and VBRI headers in those files contain only approximated info and are useless for sample-exact seeking). Therefore MP3 seeking works by bruteforce-walking the MPEG stream chain and is appropriately slow (this gets faster when you pass through the same point of file for the second time because seektables have been built in the RAM).
You need weird-ass buggy fb2k plugins, but are only missing format support in WMP? Do you play a lot of ancient tracker music or something?
If you find the fb2k interface so intimidating perhaps you'd be better off with its much simpler cousin, Boom. Not sure if it's got much support for particularly oddball media formats though.
Multi-process architecture... I've not really noticed a problem with the threaded one, and Firefox already sticks flash objects in a separate process. So what's the real draw
Isolation. The same reason you want different apps to have their own processes instead of having the whole of userspace in one big blob. You can give processes reduced privileges to reduce the scope of exploits, hangs and crashes don't take down more than they have to, and leaks don't force you to restart the entire system to recover resources.
Plus it makes for simpler concurrency. Kind of handy when you've got a stop-the-world garbage collector if you can just split the world into many smaller independent units, each able to run at the same time and each with an order of magnitude less work to do and no synchronisation to worry about.
64bit... again, bragging points about how many bits you use, no functional difference to anyone
ASLR is a fuckload more effective when it has a reasonably sized address space to work with, and 2^32 is miles away from being reasonable. It's the difference between an attacker having to guess one of 8 locations and one of 8 billion. Plus, memory mapping things is awesome, and also a fuckload easier with a reasonably sized address space.
And hey, some of us actually use our browsers quite a lot. Mine's eating 5.5G right now. So many windows and tabs, and absolutely no fucking reason whatsoever why that should be considered even slightly unreasonable.
How many people do per-user salting of the password hash?
People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.
If you're using passwords for authentication in your app, use a recognised key derivation function. Use PBKDF2 or bcrypt and tune them to take at least 100ms to run. If you're extra paranoid, use scrypt and tune it to take 100ms and 16MB of memory. If you're doing anything else without having a well-received peer reviewed academic paper describing it, you might want to reconsider.
FreeBSD uses init.d
FreeBSD uses rcNG, acquired from NetBSD (basically shell scripts and a binary for resolving dependency order defined in magic comments), on top of a simple BSD-style init. There's some vague movement towards porting launchd, but I don't think anyone's holding their breath.
pkgng's made port upgrading much less burdensome - even fairly complex dependency changes can be handled automatically as of 1.3, and the official package repositories are a lot more useful now. They even have stable security-fix-only branches.
I still make my own customised builds, but I make binary packages in an isolated jail using poudriere. 99% of upgrades are a matter of updating its ports tree, running rebuild-packages, and running pkg upgrade on all my machines.
You couldn't pay me to go back to portupgrade/portmaster/portmanager.
Not really - ports doesn't even have a *concept* of upgrading, it's just uninstall/reinstall and hope you can work out how to handle all the dependencies. This is why FreeBSD's got so many tools for managing them - portupgrade, portmanager, portmaster, all with their own little and not so little quirks.
We do have an apt-alike these days, in the form of pkgng. pkgsrc also has pkgin.
It's stable enough for general use, but maturity counts for a lot with filesystems, especially when they're as complex as ZFS. It's also a third-party add-on rather than an official part of the OS which does raise some issues.
Conversely it's practically the default on FreeBSD, and it's been available since 2008.
Every release seems to take the system one step closer to exactly what you describe
Erm, like what?
pkgng's still missing the ability to track certain changes automatically, so you occasionally have to force-remove a package or manually change an origin as per /usr/ports/UPDATING. I think they're expecting to resolve that in 1.3 fairly soon.
I've been using it for about 18 months across a small group of machines with about 1400 packages between them, and it's pretty much entirely demolished any apt-envy I've had.
You can also track the changes in a somewhat friendlier format using FreshBSD. Full commit messages (up to a point) upfront, more useful Atom feed, breakdown by committer etc.
Reality disagrees with you. The user data portion of a sector is normally a power of two for convenience, being used on computers with power of two page sizes, but drives themselves are no more limited to power of two number of or size of sectors than your computer is limited to power of two size array or structure lengths, and this is readily confirmed by the existence of disks with 520 byte sectors (and somewhat different physical sizes) and an irritatingly diverse range of sector counts.
Hard disk drives use sectors which at some basic level have to be addressed by a powers of two binary addressing system. This means that no matter what else you do with sector sizes or block sizes, the binary counting system *always* comes into the picture.
Right, they're addressed using LBA48, which happens to be encoded in binary because that's how we build computers. That doesn't imply disks naturally only support powers of two for sector counts or sizes - they evidently don't.
CDs and DVDs have 2,352 and 2,418 byte physical sectors. Some Fibre Channel HD's support 520 byte sectors, and of course like optical discs all HD's have substantially bigger physical sectors internally for error detection and correction. A quick sampling of some of my HD's reveals drives with 732,566,646, 3,907,029,168, 500,118,192 and 312,581,808 sectors (at least they're all even?).
Ethernet is even more flexible, supporting any frame sizes between 64 bytes to over 9KB, hardware permitting. Note 9KB is not a power of two.
Wrong, and wrong again. *All* computer peripherals transmit data to and from computers encoded in binary signals. It means that all computer based addressing is essentially binary
Um. Yes, the numbers are encoded in binary. No, this doesn't mean computers can only handle number maximums that are a power of two. Memory happens to be like that because it has to be insanely low latency and simple bit operations like masking off the lower portion of an address is very efficient, but not everything is so restricted.
Why always picking on the HD manufacturers? Your GigE network runs at 1,000,000,000 bits per second, not 1,073,741,824, what a scam!
Memory is measured in multiples of powers of two because that's how the addressing works. Disks and network have no such fundamental limitations - they count in sectors and frames, which are themselves not necessarily powers of two.
Note you can turn an existing FreeBSD install into PC-BSD too. Basically a case of switching pkgng to their repository, installing a metapackage and running a few bootstrap commands.
It'll perform a bit worse than a GTX Titan, which gets in the region of 330Mhash/sec. For comparison, an AMD HD5870 from 2009 managed about 400Mhash/sec.
8GB isn't hefty by any stretch of the imagination, especially not when you're messing with dedup. For decent performance the recommendation is somewhere along the lines of 20-30GB per TB, though you can mitigate that somewhat by using an SSD for L2ARC.
The transaction limits on unverified payments are pretty small (£15 here in the UK, recently raised from £10), and you'd expect any such system to be wary of lots and lots of them.
The lack of signature and PIN verification also means any liability for losses through such a system rests on the bank, not you, provided you report the loss of your card in good time. Same should apply if someone manages to exploit such a feature while you still have your card, provided you dispute the payments not too long after receiving your statement.
Firefox has Firebug; a web debugger, basically -- tracing JavaScript execution, examining and poking at the DOM, CSS, etc.
Dragonfly is the same kind of thing for Opera; and indeed, potentially other browsers which support Scope Transport Protocol.
Right, and it's less likely to die from shock or head crash or manufacturing defect, and when it runs out of erase cycles it fails soft; writes fail, but it's still readable; certainly a better failure mode than most drives. Yes, the X25-M has a 5 year design life, just as platter based drives, but I suspect it's also more likely to actually achieve it, firmware update screwups aside.
The MLC X25-M is rated at 20GB/day for a 5 year service life, why would most people care?
ATI drivers work well enough for me in Win XP, Windows Vista and Windows 7, on a HD3200, 4870 and 5870 respectively.
On the other hand the nForce 4 chipset on my motherboard died and my 8800GTS 512 died, so I tend to avoid their stuff now.
Aren't anecdotes great?
I would expect they'd be using some sort of slot, something like this. Motherboard manufacturers aren't exactly going to be thrilled at the idea of putting some yet more expensive components on there, but they might be happy to hook up a small ZIF socket thing like some of them do with CF.
Intel actually had some weird ZIF connected SSD's on there a while ago on preorder, but they appear to have disappeared.
Either way, it's nice to see some hybrid storage stuff which isn't ZFS L2ARC (zpool add tank cache /dev/my_ssd -> tank now has an 80GB SSD for fs cache). Kind of surprised it hasn't been done in software elsewhere really; you'd think there would be some Linux developer who found the idea compelling, or even Microsoft wanting to extend ReadyBoost to its logical conclusion.
I've tried an X25-M on a few servers with LSI SAS controllers (as used by PERC 6i, though I don't think I've used that exact chip) and been disappointed to encounter IO hangs and other drives disappearing randomly; even just having an X25-M plugged in is enough to seemingly make the controller rather unhappy. Doesn't appear to be a driver problem, unless it's one shared by FreeBSD, Linux and Solaris.
Hopefully Intel will do an SAS version at some point; they could compete against 15kRPM drives rather well, I think.
Intel rated the first generation X25-M's at 100GB/day for 5 years, I'd be surprised if these were significantly worse.