In my tests, gcc only optimizes out null checks at -O3 or above, which is already known to make potentially unsafe optimizations. Maybe if -Wunreachable-code were part of -Wall it would have been easier to spot.
Toady would be the first to admit the interface sucks. Future developments are listed on the main site; note the sizable Interface Arc. e.g. Core52 is "INTERFACE OVERHAUL, (Future): A coherent interface, additional options and mouse support". It'll happen when it happens, probably once more of the underlying behaviour stabilizes.
In Dwarf Fortress, at least, you have to memorize an arcane system of key commands to navigate through a literal fortress of menus
The standard display lists those key commands in the side of the window. You likely will memorize at least some of them during use, but you certainly don't have to.
An 80x50 window with 16x16 tiles takes up a quarter of my display. I normally run much bigger than that, and the tiles look pretty distinguishable to me - certainly more so than just using colours to distinguish goat from goblin and peasant from hammerdwarf.
If I need a bigger overview, d12 supports zooming; it's still usable at 8x8, but I rarely find myself wishing the standard display was that small.
Dwarf Fortress is fucking retarded. A text based game that requires Windows or OSX, 512 MB of RAM, and an OpenGL video card. No Linux and no mobile device support
Linux version. And it works fine on my laptop, great way to wile away a 4 hour train journey.
What's the point?
Um, it's a fun game? What other point do you want?
Using what encoding scheme? With a single mark the best I can think of is to treat it as a variable-length base 1 value; increment a Bignum for each atom until you hit the mark, and the final binary encoding of that is the data.
A 10TB LoC would make up a Bignum 87960930222080 bits long (and thus with a range of 0 - 2^87960930222080 - 1). Sadly with this encoding scheme the universe only contains enough atoms (~10^80) to encode about 32 bytes of that.
Re:I stopped reading the summary
on
Best eSATA JBOD?
·
· Score: 1
You missed the "encrypt it" step.
Re:I stopped reading the summary
on
Best eSATA JBOD?
·
· Score: 1
Print it, put it in a safety deposit box.
Re:I stopped reading the summary
on
Best eSATA JBOD?
·
· Score: 1
Backups are... offline
Shit. Someone tell all those people selling Amazon S3 based backup services.
Re:I stopped reading the summary
on
Best eSATA JBOD?
·
· Score: 1
Linux md RAID-1 (and a few other levels iirc) use a bitmap of changed blocks to reduce the IO required to resync a disk.
ZFS mirroring has similar behaviour, though I think they probably do something fancier with individual records rather than just a coarse bitmap of changes.
HAMMER mirroring certainly does; every write creates a new record ID and replicating systems, be they other disks or other machines entirely, can sync up their filesystem to whatever record they like, keeping around previous modifications depending on how they're configured. Yank a disk for 5 minutes, you get 5 minutes worth of writes for it to catch up on, not a resync of the entire disk.
That said, I REALLY dislike having the tab close button on the tab itself... I am still accustomed to being able to click the active tab to put it in the background -- but now, doing so closes the tab
Preferences -> Advanced -> Tabs -> Additional tab options. Check "Click on tab to minimise" and uncheck "Show close button on each tab".
Also, right click on tab bar, Customize -> Appearance, select "Wrap to multiple lines". Now you can see all your many tabs at once. You may also find it useful to have them down the left or right of the window.
The general concensus by FreeBSD users (and one shared by myself), especially those coming from a Linux background, is that the ports system Just Works(TM)
If it Just Worked, we wouldn't need to keep an eye on UPDATING and jump through hoops when upgrading certain tricky things; e.g. perl-after-upgrade, the gnome upgrade scripts, knowing when you need to forcibly rebuild dependencies and when you can just upgrade a single package, and knowing what to do when you get it wrong and it starts doing weird things like try to install already installed packages.
Ports are a leaky abstraction; they don't try to deal with every possible situation automagically like some other packaging systems, and you do need to have some vague idea what you're doing to use them well. portupgrade and co are invaluable, but they're no apt; they can't be, because the ports system doesn't give them enough information to always do the right thing by themselves.
I don't think the message ids and NNTP protocol makes that possible though, you'd need some kind of content-based hash/query system.
Message-ID's are controlled by the poster, you could embed content hashes in them quite easily; you'd just need to know any other parts of the field, which can either be fixed (content hashes should provide enough uniqueness), or detected by parsing a NZB with appropriately tagged segments. e.g:
In a NZB, this is just another segment, and it could be posted exactly as existing posts are; a torrent client, wanting data with that SHA1 hash (and a probably unnecessary byte offset and length) could request that article without knowing anything else about it (other than maybe needing to know what group it's in for some NSP's; easily solved by crossposting to, say, alt.binaries.torrentable).
The main requirement would be that the torrent client and usenet post both use the same block size.
We have widespread availability of cable and a multi-vendor ADSL network. I pay £50/month for unlimited 50Mbps, traffic management at 20Mbps and below are fairly reasonable (peak time only, then 3GB at full speed, then reduced to 5Mbps), and should Virgin get on my nerves too much I can get ADSL from two dozen different ISP's with various policies, including one very small one run by people I know (though granted, I'm only going to get about 2Mbps this far from my exchange).
In the US, I gather ADSL is only available from the (typically) one provider in a given area, so if you're lucky and have both cable and ADSL in your area you have at most two providers, who both likely repeatedly pull this kind of crap.
They have somewhere in the region of 5,000 servers in their main datacenter and (I believe) others scattered around the world, but restricting it to just that main center, that means each server is handling around 4 requests per second
I somewhat doubt every single one of them is a dynamically driven webserver. Probably at least half are databases, search servers, caching servers, backend appservers, file servers, CDN type stuff, backup servers, hot spares, admin servers, staging machines, etc.
For example: Newzbin has 5 webservers in main rotation; it also has 7 search servers (plus one development machine with similar specs), 6 database machines, 2 backend systems running most of our cronjobs, 2 admin servers, 1 web development server, and 2 systems for building and deploying OS's from. As far as load is concerned, the backend stuff is far more important than the frontend. Sure, we could rewrite the main site in Java or Scala or C++ and get away with 3 webservers and still be N+2, but trust me, those extra two or three webservers is not a significant cost next to that of development.
I can either spend £5k on extra equipment (plus occasionally boosting our space and bandwidth costs, but those are dominated by other systems already), or I can spend £70k a year on another developer, who *still* won't allow us to match our development speed with PHP, and then rewrite tens of thousands of lines of code, likely into much more.
Much of our backend is written in C. That's where the big payoffs for efficient languages is, not a bit of database-limited HTML rendering. Judging by how many big sites are still running PHP, Python and Ruby for their frontends, this would seem to be the case elsewhere, too.
1. is no longer true since 7.1; the kernel address space is now big enough for tuning to typically be unnecessary (unless you're on i386, in which case you deserve your pain, even on Solaris).
Many of the remaining problems are gone in -CURRENT, but even with 7.0 my experience is that ZFS is stable enough for general use. Indeed, some people are running it successfully in production; FreeBSD package building, for instance.
Slashdot Mirror
In my tests, gcc only optimizes out null checks at -O3 or above, which is already known to make potentially unsafe optimizations. Maybe if -Wunreachable-code were part of -Wall it would have been easier to spot.
Why assume anything? I've been using the RC for 6 weeks, nothing wrong with it. Good step up from XP.
Toady would be the first to admit the interface sucks. Future developments are listed on the main site; note the sizable Interface Arc. e.g. Core52 is "INTERFACE OVERHAUL, (Future): A coherent interface, additional options and mouse support". It'll happen when it happens, probably once more of the underlying behaviour stabilizes.
In Dwarf Fortress, at least, you have to memorize an arcane system of key commands to navigate through a literal fortress of menus
The standard display lists those key commands in the side of the window. You likely will memorize at least some of them during use, but you certainly don't have to.
An 80x50 window with 16x16 tiles takes up a quarter of my display. I normally run much bigger than that, and the tiles look pretty distinguishable to me - certainly more so than just using colours to distinguish goat from goblin and peasant from hammerdwarf.
If I need a bigger overview, d12 supports zooming; it's still usable at 8x8, but I rarely find myself wishing the standard display was that small.
Dwarf Fortress is fucking retarded. A text based game that requires Windows or OSX, 512 MB of RAM, and an OpenGL video card. No Linux and no mobile device support
Linux version. And it works fine on my laptop, great way to wile away a 4 hour train journey.
What's the point?
Um, it's a fun game? What other point do you want?
Using what encoding scheme? With a single mark the best I can think of is to treat it as a variable-length base 1 value; increment a Bignum for each atom until you hit the mark, and the final binary encoding of that is the data.
A 10TB LoC would make up a Bignum 87960930222080 bits long (and thus with a range of 0 - 2^87960930222080 - 1). Sadly with this encoding scheme the universe only contains enough atoms (~10^80) to encode about 32 bytes of that.
You define the randomness of data by how compressible it is, duh
For 4k of data:
You missed the "encrypt it" step.
Print it, put it in a safety deposit box.
Backups are ... offline
Shit. Someone tell all those people selling Amazon S3 based backup services.
Linux md RAID-1 (and a few other levels iirc) use a bitmap of changed blocks to reduce the IO required to resync a disk.
ZFS mirroring has similar behaviour, though I think they probably do something fancier with individual records rather than just a coarse bitmap of changes.
HAMMER mirroring certainly does; every write creates a new record ID and replicating systems, be they other disks or other machines entirely, can sync up their filesystem to whatever record they like, keeping around previous modifications depending on how they're configured. Yank a disk for 5 minutes, you get 5 minutes worth of writes for it to catch up on, not a resync of the entire disk.
Hibernate is only about 5 seconds faster than a normal boot here; X25-M, 12GB i7. Maybe it'll help more when you don't have a 9GB hiberfil.sys :)
You can have your cake and eat it in 7-STABLE with ZFS v13; it has functional L2ARC support.
Or go for both and use the SSD as cache.
That said, I REALLY dislike having the tab close button on the tab itself ... I am still accustomed to being able to click the active tab to put it in the background -- but now, doing so closes the tab
Preferences -> Advanced -> Tabs -> Additional tab options. Check "Click on tab to minimise" and uncheck "Show close button on each tab".
Also, right click on tab bar, Customize -> Appearance, select "Wrap to multiple lines". Now you can see all your many tabs at once. You may also find it useful to have them down the left or right of the window.
The general concensus by FreeBSD users (and one shared by myself), especially those coming from a Linux background, is that the ports system Just Works(TM)
If it Just Worked, we wouldn't need to keep an eye on UPDATING and jump through hoops when upgrading certain tricky things; e.g. perl-after-upgrade, the gnome upgrade scripts, knowing when you need to forcibly rebuild dependencies and when you can just upgrade a single package, and knowing what to do when you get it wrong and it starts doing weird things like try to install already installed packages.
Ports are a leaky abstraction; they don't try to deal with every possible situation automagically like some other packaging systems, and you do need to have some vague idea what you're doing to use them well. portupgrade and co are invaluable, but they're no apt; they can't be, because the ports system doesn't give them enough information to always do the right thing by themselves.
I don't think the message ids and NNTP protocol makes that possible though, you'd need some kind of content-based hash/query system.
Message-ID's are controlled by the poster, you could embed content hashes in them quite easily; you'd just need to know any other parts of the field, which can either be fixed (content hashes should provide enough uniqueness), or detected by parsing a NZB with appropriately tagged segments. e.g:
In a NZB, this is just another segment, and it could be posted exactly as existing posts are; a torrent client, wanting data with that SHA1 hash (and a probably unnecessary byte offset and length) could request that article without knowing anything else about it (other than maybe needing to know what group it's in for some NSP's; easily solved by crossposting to, say, alt.binaries.torrentable).
The main requirement would be that the torrent client and usenet post both use the same block size.
This has already been largely fixed in 7.1, with the kernel address space expanded to 6GB.
If you're still on 32bit, well, ZFS will hate you for that in Solaris too.
Both 7.1-STABLE and 7.2-PRERELEASE are in the same branch; stable/7 or RELENG_7.
We have widespread availability of cable and a multi-vendor ADSL network. I pay £50/month for unlimited 50Mbps, traffic management at 20Mbps and below are fairly reasonable (peak time only, then 3GB at full speed, then reduced to 5Mbps), and should Virgin get on my nerves too much I can get ADSL from two dozen different ISP's with various policies, including one very small one run by people I know (though granted, I'm only going to get about 2Mbps this far from my exchange).
In the US, I gather ADSL is only available from the (typically) one provider in a given area, so if you're lucky and have both cable and ADSL in your area you have at most two providers, who both likely repeatedly pull this kind of crap.
They have somewhere in the region of 5,000 servers in their main datacenter and (I believe) others scattered around the world, but restricting it to just that main center, that means each server is handling around 4 requests per second
I somewhat doubt every single one of them is a dynamically driven webserver. Probably at least half are databases, search servers, caching servers, backend appservers, file servers, CDN type stuff, backup servers, hot spares, admin servers, staging machines, etc.
For example: Newzbin has 5 webservers in main rotation; it also has 7 search servers (plus one development machine with similar specs), 6 database machines, 2 backend systems running most of our cronjobs, 2 admin servers, 1 web development server, and 2 systems for building and deploying OS's from. As far as load is concerned, the backend stuff is far more important than the frontend. Sure, we could rewrite the main site in Java or Scala or C++ and get away with 3 webservers and still be N+2, but trust me, those extra two or three webservers is not a significant cost next to that of development.
I can either spend £5k on extra equipment (plus occasionally boosting our space and bandwidth costs, but those are dominated by other systems already), or I can spend £70k a year on another developer, who *still* won't allow us to match our development speed with PHP, and then rewrite tens of thousands of lines of code, likely into much more.
Much of our backend is written in C. That's where the big payoffs for efficient languages is, not a bit of database-limited HTML rendering. Judging by how many big sites are still running PHP, Python and Ruby for their frontends, this would seem to be the case elsewhere, too.
We're really looking forward to the changes that FreeBSD 8.0 will bring, as it includes ZFS v13, removes the 2 GB kmem barrier
Already in 7.1.
1. is no longer true since 7.1; the kernel address space is now big enough for tuning to typically be unnecessary (unless you're on i386, in which case you deserve your pain, even on Solaris).
Many of the remaining problems are gone in -CURRENT, but even with 7.0 my experience is that ZFS is stable enough for general use. Indeed, some people are running it successfully in production; FreeBSD package building, for instance.
No, it's like how vendor drives have actually been tested and packaged up nicely.
Personally I think I'd rather get 3 cold spares with my replacement; no matter what Apple do, they're still going to fail at about 1% per year.