Really... it is not up to us to solve this problem for "starting artists".
We don't have to come up with a new model that works to justify taking a product for free that has essentially no value anymore. Infact, I will not even consider supporting a model that is based on "number of plays" or "number of sales". No-one is entitled to make money of a one-time effort in perpetuity.
Copyright is one such model I will not support and is unsustainable in the long run. Our tools to ignore and circumvent it are only the very early stages of development. Here's a few things that will make it unsustainable:
- Bandwidth and Compression will eventually outpace any advances made in higher quality video. It already outpaces music with no hope of recovery making a music download a thing that just takes mere seconds and that much harder to trace.
- Related to bandwidth, as bandwidth increases, using onion style routing and encryption becomes practical. It already is practical for low bandwidth stuff like music.
- Storage capacity. It is not inconceivable I can swap thumbsized memory cards containing all music released EVER with my friends in just a few years time.
- Networks controlled by the community. We used to have this in the BBS days, and it will return if we're pushed hard enough in the form of WiFi style networks with a global reach, occasionally tunneling over the internet with heavy encryption.
Let's not get into the issues of what it would take to police copyright infringement. The amount of invasion of privacy required would be unsustainable.
That's like saying you cannot model a bouncing ball because you are unable to model all the subatomic particles involved.
Modeling macroscopic behaviour does not require knowledge of every particle involved. It is well known that a large group of humans is actually more predictable than a small group or an individual, and I'm sure you can apply many general equations to them, even physics ones to gain insight in our group behaviour.
Some of my thoughts:
- Population growth and economic growth are closely related - Exponential population growth cannot be maintained forever -- it is undeniable that humans are having a huge effect on the environment, and are causing extinctions on massive scales -- imagine how it will look when we pass the 10 billion and 15 billion marks - As a result of the population growth, any mammal larger than a rat is going to go extinct where humans can live, apart from livestock
I once used a C compiler, a fairly popular one that had been in use for years already. I discovered my program had a bug in it when using a certain number of variables 5 or 6 nesting levels deep. After some long hours I started thinking it was the compiler. Looking at the disassembly I noticed a register was not properly initialized. I mailed the authors a sample program demonstrating the bug (sample program was about 30 lines, couldn't make it shorter and still have it display the bug). Three days later I got a patch back with a fix.
C compiler's have bugs. Even Processors have bugs. It would not be the first thing I'd look for, but I wouldn't rule it out.
It doesn't actually "move" data. The so-called 32-bit x86 CPU's that support PAE infact have a 36-bits address bus, allowing the CPU to address 64 GB of memory using memory mapping.
The memory is divided up into small blocks (usually 4 or 8 kB) called pages. Special tables are used to create a map of pages for each process. This map determines which physical page maps to which page in the process' address space. So page 0 in the process' address space can be any physical page you want it to be, determined by a translation table. The translation table contains 36-bit offsets which are used by the CPU to dynamically translate a page in the process' address space to the correct physical page. There's absolutely no copying involved.
This of course still limits the address space a process can see to 4 GB, but multiple processes can use more than 4 GB of RAM. The overhead is infact minimal. It's in fact a similar mechanism as is used to implement Swap space, if not the same mechanism.
Windows 2003 is nothing more than Windows XP with some extra services bolted on. I can't even tell the difference between 2003 and XP, certainly not from a developer/gamer perspective (yes, I use it as a gaming platform).
This is just typical marketing bullshit where PAE is disabled to sell more expensive copies, just like creating Software Raids is disabled in XP, but if you happen to create the array in some other way, then it will suddenly happily use your raid without problems.
IMHO, GC on SSD's is not going to be good enough, 512 kB blocks are way too large. Instead, they should build SSD's that can erase smaller blocks.
There's good reason most filesystems donot use extremely large blocksizes:
1) Using large block sizes means you reduce the maximum IO operations/second (something which SSD's are supposed to be good at). On traditional Hard Drives, you won't notice this until you go past 64 kB due to seek latency taking the largest part of such a transfer. On SSD's however you may notice this much earlier since there's supposed to be almost no seek time, meaning that the biggest advantage of SSD's (low latency) basically gets nullified if you started using insanely large blocks in your filesystem.
2) Cached blocks will contain more junk that was never requested (a cache with 1k granularity can hold far more pertinent data than one with 64 kB blocks)
3) Tail packing is no longer optional when using larger block sizes. Filesystems that donot support this therefore are unsuitable.
4) In memory manipulation of large block sizes could also affect performance (like rehashing/checksumming data, re-arranging block contents) depending on algorithms used.
5) Using larger blocksizes means the FS will likely rewrite such a block MORE often, as it contains more updatable data and more "free" space to add new data. Filesystems that never rewrite blocks won't be spared either as those blocks still need to be written somewhere (just not "overwritten") -- this makes keeping snapshots or going back in time a lot less efficient too. Writing such a large block will still require an Erase + Write, and always a full transfer of 512 kB (which takes 1.6 ms @ 300 MB/s -- quite close to the seek latency of traditional drives).
There's probably more good reasons. I don't see the new filesystems fixing them all. Half a megabyte block sizes are really insanely large. It reminds me of FAT16 filesystems storing a 20 byte file in a 32k block -- your basically throwing around huge amounts of data for even the smallest of operations...
The worst thing you can possibly do in a UI is hide stuff inconsistently (ie, outside of user control) or move stuff around.
For example, hiding menu options based on use patterns. What purpose does this serve? To save screen space? The user remembers the option they want (if they donot use the hotkey) by placement (almost at the top, just below the middle, etc). Hiding options screws this up. These experts seem to believe users actually READ all the options (or look at icons or something). They don't. They just remember that the recycler was somewhere bottom right, the file menu with open option is top left, tools is somewhere on the right side next to help, etc..
The same thing goes for moving options around, it doesn't matter for what reason. Moving them around means that the option that was in the right corner last week is suddenly somewhere in the middle this week -- mega fail.
Surface scans with SMART already catch these problems (blocks going bad).
There's no need to check for single bit errors in files / blocks themselves as that's never gonna happen when the block was either fully error corrected by the drive or simply not returned at all due to a checksum failure (in which case it's a bad block).
If a checksum DOES fail in such a setup (with the filesystem doing the check), it is actually more likely that it was damaged in memory (which could be fixed by simply reading it again). Damage in memory is sinister though as you never know when a (cached) block gets damaged, which could be never or right after the checksumming process declares it "correct".
If you are really worried about these issues, I'd first invest in an ECC capable motherboard and ECC memory.
If the checksumming is done by the CPU, on non-ECC memory, you might as well not use it as the data is most likely going to get corrupted at the source (your memory) not in transfer.
The biggest source of bit errors at the moment is non-ECC memory as far as I can tell. Most busses are already protected in some form due to their high-speed nature. Hard drives themselves use many forms of error correction routinely to even read any sane data at all.
On my own system I noticed a problem when copying large amounts of data (which was checksummed in some other fashion) that I'd get about 1 bit error for every 100 GB of data copied. This came up fairly often, and is the reason I now always use mv/cp tools that can do a verify. After I replaced the memory with ECC variants however these tools haven't reported an error since.
I just fear that feeding the world and using food more efficiently only really delays the problem again (as population will simply increase upto a point where we have the same problem again). The ecological impact of the current 6 billion people is already starting to be felt on a global scale (in the forms of climate change, deforestation, species becoming extinct). I'm not so sure we want to feed the world and quickly breed 6 billion more. With that many people food problems may be the least of our worries.
Just work on allowing sites to use encryption without a certificate. Don't display a "lock" icon if you have to, just let everyone use encryption freely, and we'll have a fully encrypted WWW in a matter of years.
Just think about it... everything encrypted -- just the increased volume of encrypted communications alone will probably make an attacker's life a lot harder.
There's ALWAYS a good reason to use encryption, in fact, everything you do on the internet should be encrypted by default. It raises the bar for any would be attacker at almost zero cost to you. It for example makes it harder to distinguish between what's interesting for an attacker and what isn't (since everything is encrypted, even trivial stuff).
The certificate system is the problem, not sites using encryption without authentication.
If there was an option to just get encryption, without the certificates, without all this hassle, we would see SSL usage skyrocket -- I daresay that because of this mess we're still using plain-text HTTP most of the time -- something that would-be-attackers (and governments) probably find very convenient.
More SSL is a good thing, because the less data goes unencrypted over the internet the better. It doesn't matter that it's not at same as a fully properly authenticated site (and whether that is safe seems to be a point of discussion), the point is that it is far safer than the alternative: plain HTTP.
Slashdot Mirror
Really... it is not up to us to solve this problem for "starting artists".
We don't have to come up with a new model that works to justify taking a product for free that has essentially no value anymore. Infact, I will not even consider supporting a model that is based on "number of plays" or "number of sales". No-one is entitled to make money of a one-time effort in perpetuity.
Copyright is one such model I will not support and is unsustainable in the long run. Our tools to ignore and circumvent it are only the very early stages of development. Here's a few things that will make it unsustainable:
- Bandwidth and Compression will eventually outpace any advances made in higher quality video. It already outpaces music with no hope of recovery making a music download a thing that just takes mere seconds and that much harder to trace.
- Related to bandwidth, as bandwidth increases, using onion style routing and encryption becomes practical. It already is practical for low bandwidth stuff like music.
- Storage capacity. It is not inconceivable I can swap thumbsized memory cards containing all music released EVER with my friends in just a few years time.
- Networks controlled by the community. We used to have this in the BBS days, and it will return if we're pushed hard enough in the form of WiFi style networks with a global reach, occasionally tunneling over the internet with heavy encryption.
Let's not get into the issues of what it would take to police copyright infringement. The amount of invasion of privacy required would be unsustainable.
A system that is unhackable like that will however never become popular enough for me to want to get the content for it for free.
That's like saying you cannot model a bouncing ball because you are unable to model all the subatomic particles involved.
Modeling macroscopic behaviour does not require knowledge of every particle involved. It is well known that a large group of humans is actually more predictable than a small group or an individual, and I'm sure you can apply many general equations to them, even physics ones to gain insight in our group behaviour.
Some of my thoughts:
- Population growth and economic growth are closely related
- Exponential population growth cannot be maintained forever -- it is undeniable that humans are having a huge effect on the environment, and are causing extinctions on massive scales -- imagine how it will look when we pass the 10 billion and 15 billion marks
- As a result of the population growth, any mammal larger than a rat is going to go extinct where humans can live, apart from livestock
Funny.. that's like saying, no, it doesn't eat puppies... it eats baby seals.
That sucks... at least in jail I would still have internet.
$10? I got 2nd hand HD's lying around that I give away free that are bigger than memory sticks.
This is wrong. It's:
TB:1,099,511,627,776
TiB: Does not compute
Actually, no we don't.
I once used a C compiler, a fairly popular one that had been in use for years already. I discovered my program had a bug in it when using a certain number of variables 5 or 6 nesting levels deep. After some long hours I started thinking it was the compiler. Looking at the disassembly I noticed a register was not properly initialized. I mailed the authors a sample program demonstrating the bug (sample program was about 30 lines, couldn't make it shorter and still have it display the bug). Three days later I got a patch back with a fix.
C compiler's have bugs. Even Processors have bugs. It would not be the first thing I'd look for, but I wouldn't rule it out.
Ehr, right...
It doesn't actually "move" data. The so-called 32-bit x86 CPU's that support PAE infact have a 36-bits address bus, allowing the CPU to address 64 GB of memory using memory mapping.
The memory is divided up into small blocks (usually 4 or 8 kB) called pages. Special tables are used to create a map of pages for each process. This map determines which physical page maps to which page in the process' address space. So page 0 in the process' address space can be any physical page you want it to be, determined by a translation table. The translation table contains 36-bit offsets which are used by the CPU to dynamically translate a page in the process' address space to the correct physical page. There's absolutely no copying involved.
This of course still limits the address space a process can see to 4 GB, but multiple processes can use more than 4 GB of RAM. The overhead is infact minimal. It's in fact a similar mechanism as is used to implement Swap space, if not the same mechanism.
Plausible my ass.
Windows 2003 is nothing more than Windows XP with some extra services bolted on. I can't even tell the difference between 2003 and XP, certainly not from a developer/gamer perspective (yes, I use it as a gaming platform).
This is just typical marketing bullshit where PAE is disabled to sell more expensive copies, just like creating Software Raids is disabled in XP, but if you happen to create the array in some other way, then it will suddenly happily use your raid without problems.
Yup, Windows 2003 here, 8 GB of RAM, 32 bit + PAE. Never gives any trouble and it's a gaming rig.
1) Rename class member in Python
2) Watch chaos ensue
It's stopped by the stupid valid certificate requirement.
Ah yes, you are another one of those people who think that if the authorities have "a really good reason", then it should be enough.
I prefer evidence.
IMHO, GC on SSD's is not going to be good enough, 512 kB blocks are way too large. Instead, they should build SSD's that can erase smaller blocks.
There's good reason most filesystems donot use extremely large blocksizes:
1) Using large block sizes means you reduce the maximum IO operations/second (something which SSD's are supposed to be good at). On traditional Hard Drives, you won't notice this until you go past 64 kB due to seek latency taking the largest part of such a transfer. On SSD's however you may notice this much earlier since there's supposed to be almost no seek time, meaning that the biggest advantage of SSD's (low latency) basically gets nullified if you started using insanely large blocks in your filesystem.
2) Cached blocks will contain more junk that was never requested (a cache with 1k granularity can hold far more pertinent data than one with 64 kB blocks)
3) Tail packing is no longer optional when using larger block sizes. Filesystems that donot support this therefore are unsuitable.
4) In memory manipulation of large block sizes could also affect performance (like rehashing/checksumming data, re-arranging block contents) depending on algorithms used.
5) Using larger blocksizes means the FS will likely rewrite such a block MORE often, as it contains more updatable data and more "free" space to add new data. Filesystems that never rewrite blocks won't be spared either as those blocks still need to be written somewhere (just not "overwritten") -- this makes keeping snapshots or going back in time a lot less efficient too. Writing such a large block will still require an Erase + Write, and always a full transfer of 512 kB (which takes 1.6 ms @ 300 MB/s -- quite close to the seek latency of traditional drives).
There's probably more good reasons. I don't see the new filesystems fixing them all. Half a megabyte block sizes are really insanely large. It reminds me of FAT16 filesystems storing a 20 byte file in a 32k block -- your basically throwing around huge amounts of data for even the smallest of operations...
Nah, the actual goal was that they needed an extra bullet-point on the box for marketing purposes.
The worst thing you can possibly do in a UI is hide stuff inconsistently (ie, outside of user control) or move stuff around.
For example, hiding menu options based on use patterns. What purpose does this serve? To save screen space? The user remembers the option they want (if they donot use the hotkey) by placement (almost at the top, just below the middle, etc). Hiding options screws this up. These experts seem to believe users actually READ all the options (or look at icons or something). They don't. They just remember that the recycler was somewhere bottom right, the file menu with open option is top left, tools is somewhere on the right side next to help, etc..
The same thing goes for moving options around, it doesn't matter for what reason. Moving them around means that the option that was in the right corner last week is suddenly somewhere in the middle this week -- mega fail.
Yeah, it's only 139.000 more than the number of politicians voted into office.
No need, the apple logo has the same effect for me.
Surface scans with SMART already catch these problems (blocks going bad).
There's no need to check for single bit errors in files / blocks themselves as that's never gonna happen when the block was either fully error corrected by the drive or simply not returned at all due to a checksum failure (in which case it's a bad block).
If a checksum DOES fail in such a setup (with the filesystem doing the check), it is actually more likely that it was damaged in memory (which could be fixed by simply reading it again). Damage in memory is sinister though as you never know when a (cached) block gets damaged, which could be never or right after the checksumming process declares it "correct".
If you are really worried about these issues, I'd first invest in an ECC capable motherboard and ECC memory.
If the checksumming is done by the CPU, on non-ECC memory, you might as well not use it as the data is most likely going to get corrupted at the source (your memory) not in transfer.
The biggest source of bit errors at the moment is non-ECC memory as far as I can tell. Most busses are already protected in some form due to their high-speed nature. Hard drives themselves use many forms of error correction routinely to even read any sane data at all.
On my own system I noticed a problem when copying large amounts of data (which was checksummed in some other fashion) that I'd get about 1 bit error for every 100 GB of data copied. This came up fairly often, and is the reason I now always use mv/cp tools that can do a verify. After I replaced the memory with ECC variants however these tools haven't reported an error since.
I just fear that feeding the world and using food more efficiently only really delays the problem again (as population will simply increase upto a point where we have the same problem again). The ecological impact of the current 6 billion people is already starting to be felt on a global scale (in the forms of climate change, deforestation, species becoming extinct). I'm not so sure we want to feed the world and quickly breed 6 billion more. With that many people food problems may be the least of our worries.
Just work on allowing sites to use encryption without a certificate. Don't display a "lock" icon if you have to, just let everyone use encryption freely, and we'll have a fully encrypted WWW in a matter of years.
Just think about it... everything encrypted -- just the increased volume of encrypted communications alone will probably make an attacker's life a lot harder.
There's ALWAYS a good reason to use encryption, in fact, everything you do on the internet should be encrypted by default. It raises the bar for any would be attacker at almost zero cost to you. It for example makes it harder to distinguish between what's interesting for an attacker and what isn't (since everything is encrypted, even trivial stuff).
The certificate system is the problem, not sites using encryption without authentication.
If there was an option to just get encryption, without the certificates, without all this hassle, we would see SSL usage skyrocket -- I daresay that because of this mess we're still using plain-text HTTP most of the time -- something that would-be-attackers (and governments) probably find very convenient.
More SSL is a good thing, because the less data goes unencrypted over the internet the better. It doesn't matter that it's not at same as a fully properly authenticated site (and whether that is safe seems to be a point of discussion), the point is that it is far safer than the alternative: plain HTTP.