You'd be able to prove your vote to a third party. This means that buying votes becomes very practical. The main defense against vote-buying at the moment is the fact that nobody can determine if the vote seller actually went through with their end of the bargain, and so it's a very iffy investment (I'd gladly take money for voting for McCain if I couldn't be held responsible for not following through, after all)
Short of removing the boot CF card and BIOS flash from the machine, and dumping them with a known-good machine, how does one verify that the machine was not tampered with? The BIOS could inject system management mode hooks to mess with votes for example - apart from a few microseconds of latency here and there, the OS would be none the wiser.
And if you/do/ dump the BIOS and CF card using some machine known good to one party, how does the other party know you didn't reflash it while you were in possession of that hardware?
Proving that a given piece of hardware is running a known piece of software is not as easy as you may think... Particularly when the hardware manufacturer (Hi, diebold!) is known for having a spotty security history. Although this doesn't mean they're deliberately trying to cause vulnerabilities, I would hope that the start of the chain of trust has been as thoroughly audited as the end.
pick your worse nightmare, start a cancer or cause a mutation.
Mutations that/don't/ lead to cancer seem rather unlikely to lead to systemic issues - sure, that one cell might be broken, but the others are doing fine.
The origin of the 'twice real RAM' came in the early days of windows, in which windows could not use any swap unless you had at least as much as real RAM. That's been gone for ages now - and you should actively avoid too much swap.
If you allocate, say, 8G of swap for 4G of RAM, most of the time almost all of it will go unused. If it actually/is/ used, your machine has probably spent the past hour or so frantically swapping to try to accomidate this 12G request; ie, your system is completely unresponsive due to every program being mostly swapped out. The additional swap merely delays the out of memory event, and in the meantime you can't control the machine.
Swap is still useful for holding data that's not part of the working set, in order to free memory for cache; but this shouldn't be very much RAM (256-512mb should be enough). It's also useful for software suspend on linux - if you have a laptop, make it a little bit larger than physical RAM. And always have/some/ - linux's memory manager doesn't like having none.
The 'no warranty' issue could be shown during ubuntu's installation as a whole, as it applies to everything in ubuntu. As for sending data to google - it shouldn't present this as a eula; it should present it as a very clear/option/ at the first run; just like IE7 does.
The rights do stay with the uploader. But Google needs a license from the uploader to display the material at all - and that's the purpose of the relevant segment of the TOS. As for promotional images, it'd make sense that they can take screenshots and etc of their service, no? If you want a service that promises never to commercialize your content ever, you should be paying for it. And the promotional rights terminate as well "within a commercially reasonable period after such Content is removed"
Writing data to the drive once is always going to be enough that you can't just 'dd' it back out. As far as the drive is concerned, all that randomized cruft, or indeed a long string of zeros, is perfectly valid data that it must preserve, so it's not about to return other data instead (unless it's malfunctioning in an interesting way, in which case you have other problems). The question is if you can do better with specialized equipment... but the prize isn't enough for it to be worth it.
It's quite simple actually. Go to wikipedia's article on spaces and copypaste U+2060 ('word joiner') into the middle of the domain. Then carefully remove the brackets around it (you will be able to tell it's there because you will have to use left/right arrow keys twice to get past it). Now the resulting text won't trip facebook's filter.
Re:Non-Tech Percent of Web Traffic from Chrome
on
Google Chrome, Day 2
·
· Score: 5, Informative
Because some foolish web developers disable functionality if they don't see what they expect in the user-agent. As a result, every web browser in existence lies in their user agent string. IE claims to be "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)", for example
Competition is a good thing. Google can push to improve the features they'd like to improve in this browser; if it's better than firefox and IE, it'll push those to improve as well. It benefits nobody to become complacent. Moreover, by making KHTML/Webkit an even more important rendering engine, it will become less possible to ignore web standards and code to the browsers that happen to be out there. Since it's going to be open source, I don't think there's anything to worry about here, really.
Because it allows them to express in a clear and concise way what operations they wish to allow on the font - and allows user agents to inform the web developer when they may be infringing upon the copyright. Of course, it's trivially removable, but this avoids the case where someone embeds a font in violation of its license because they didn't realize it was copyrightable.
The "DRM" doesn't even matter. Since the format spec is public, you can do whatever you want to the data anyway. It'd be trivial to strip out all that stuff, and if EOT takes off, I'm sure you'll be able to find such utilities all over the place. Rather than DRM, it's more of an advisory flag - keeping the honest people honest, and the slightly mischievous people can read the spec, and write the trivial remover program; or remove the check from $browser.
It's even more interesting to note that there's actually no DRM in the submitted spec - there's a field (at a fixed location, which you can zero out if you really want to) that gives a machine-readable license statement, and, for some (legacy?) reason, an XOR-by-0x50 cipher, and the option of using subsetting to reduce font sizes at the expense of having to regenerate the font when the website changes. That's it. Nothing else.
There are two issues here, that slashdot combines, and neither of them are DRM. First, characters not used on the page may be dropped from the font to save space - this isn't DRM, just a bandwidth saving measure. This is why the EOT fonts, if subsetted, must be regenerated if your site changed - while it may be annoying, depending on the implementation, there are no restrictions on the renderer, nor is this a required portion of the spec.
Second, there are embedding flags (EOT spec, 4.1). These are essentially a machine-readable copyright and license statement - it is absolutely trivial to manipulate this field. You could do it in a few dozen lines of code in the programming language of your choice, with no need to reverse engineer, drag out keys, whatever.
In short, nothing to see here. This slashdot article makes a big deal out of absolutely nothing.
Good luck linking a binary blob into the rendering engine in a way that doesn't allow you to slurp it out by modifying said rendering engine. Moreover, what possible benefit would Mozilla have from such an action? It would just burn bridges, with no real benefit.
It's all moot anyway though - if anyone actually bothers to read the spec, there's no DRM - you only need to regenerate it because the fonts are compressed by removing characters not used by the page in question (which is a reasonable idea, although possibly a bit annoying depending on the implementation). There are bits controlling embedding permissions, but this is trivial to work around. They're better thought of as a machine-readable license statement; it's trivial to read them, replace them, ignore them, whatever, all in a nicely GPLv3'd debian package consisting of a few dozen lines of C code if you want.
Simply put, Firefox now has enough audience that web designers can't ignore it. Either EOT can be implemented with open-source code in firefox, which means its decryption scheme will be right out there in the open (and firefox can even simply fail to implement the DRM portions) - or it will only work in IE, which means it's unlikely to be used anywhere it matters.
This filesystem is meant for embedded devices with Flash storage that presents itself as a portion of physical memory - essentially, it helps the kernel avoid the overhead of copying from Flash to RAM when you can just run it out of Flash.
XiP has been supported in other filesystems, this is more like a small improvement - nothing to get excited about. Moreover, you won't see it in use in any desktops - this filesystem is read-only; more like an archive format understood by the kernel.
More useful discussion can be found at kerneltrap.
Slashdot Mirror
I'd be more worried that their digital signature chain scheme might not be verified properly, myself.
Also, you wouldn't need a hardware hack - the BIOS can inject System management mode hooks to do all kinds of fun, on x86 platforms.
You'd be able to prove your vote to a third party. This means that buying votes becomes very practical. The main defense against vote-buying at the moment is the fact that nobody can determine if the vote seller actually went through with their end of the bargain, and so it's a very iffy investment (I'd gladly take money for voting for McCain if I couldn't be held responsible for not following through, after all)
Short of removing the boot CF card and BIOS flash from the machine, and dumping them with a known-good machine, how does one verify that the machine was not tampered with? The BIOS could inject system management mode hooks to mess with votes for example - apart from a few microseconds of latency here and there, the OS would be none the wiser.
And if you /do/ dump the BIOS and CF card using some machine known good to one party, how does the other party know you didn't reflash it while you were in possession of that hardware?
Proving that a given piece of hardware is running a known piece of software is not as easy as you may think... Particularly when the hardware manufacturer (Hi, diebold!) is known for having a spotty security history. Although this doesn't mean they're deliberately trying to cause vulnerabilities, I would hope that the start of the chain of trust has been as thoroughly audited as the end.
Mutations that /don't/ lead to cancer seem rather unlikely to lead to systemic issues - sure, that one cell might be broken, but the others are doing fine.
Here is my source: http://blogs.smugmug.com/don/2008/05/01/mysql-and-the-linux-swap-problem/. It could be that it only shows on certain heavy workloads.
Here's the article I saw on it: http://blogs.smugmug.com/don/2008/05/01/mysql-and-the-linux-swap-problem/
The origin of the 'twice real RAM' came in the early days of windows, in which windows could not use any swap unless you had at least as much as real RAM. That's been gone for ages now - and you should actively avoid too much swap.
If you allocate, say, 8G of swap for 4G of RAM, most of the time almost all of it will go unused. If it actually /is/ used, your machine has probably spent the past hour or so frantically swapping to try to accomidate this 12G request; ie, your system is completely unresponsive due to every program being mostly swapped out. The additional swap merely delays the out of memory event, and in the meantime you can't control the machine.
Swap is still useful for holding data that's not part of the working set, in order to free memory for cache; but this shouldn't be very much RAM (256-512mb should be enough). It's also useful for software suspend on linux - if you have a laptop, make it a little bit larger than physical RAM. And always have /some/ - linux's memory manager doesn't like having none.
In the case of GMod, it went to a pay model; these mods are being distributed for free.
The 'no warranty' issue could be shown during ubuntu's installation as a whole, as it applies to everything in ubuntu. As for sending data to google - it shouldn't present this as a eula; it should present it as a very clear /option/ at the first run; just like IE7 does.
The rights do stay with the uploader. But Google needs a license from the uploader to display the material at all - and that's the purpose of the relevant segment of the TOS. As for promotional images, it'd make sense that they can take screenshots and etc of their service, no? If you want a service that promises never to commercialize your content ever, you should be paying for it. And the promotional rights terminate as well "within a commercially reasonable period after such Content is removed"
Writing data to the drive once is always going to be enough that you can't just 'dd' it back out. As far as the drive is concerned, all that randomized cruft, or indeed a long string of zeros, is perfectly valid data that it must preserve, so it's not about to return other data instead (unless it's malfunctioning in an interesting way, in which case you have other problems). The question is if you can do better with specialized equipment... but the prize isn't enough for it to be worth it.
However, you can pad out the start with zeroes.
It's quite simple actually. Go to wikipedia's article on spaces and copypaste U+2060 ('word joiner') into the middle of the domain. Then carefully remove the brackets around it (you will be able to tell it's there because you will have to use left/right arrow keys twice to get past it). Now the resulting text won't trip facebook's filter.
Because some foolish web developers disable functionality if they don't see what they expect in the user-agent. As a result, every web browser in existence lies in their user agent string. IE claims to be "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)", for example
Yes, and google chrome does this automatically.
In the actual comic, it was sort of mentioned in passing. The real big deal is isolating tabs at the process level.
Competition is a good thing. Google can push to improve the features they'd like to improve in this browser; if it's better than firefox and IE, it'll push those to improve as well. It benefits nobody to become complacent. Moreover, by making KHTML/Webkit an even more important rendering engine, it will become less possible to ignore web standards and code to the browsers that happen to be out there. Since it's going to be open source, I don't think there's anything to worry about here, really.
Because it allows them to express in a clear and concise way what operations they wish to allow on the font - and allows user agents to inform the web developer when they may be infringing upon the copyright. Of course, it's trivially removable, but this avoids the case where someone embeds a font in violation of its license because they didn't realize it was copyrightable.
The "DRM" doesn't even matter. Since the format spec is public, you can do whatever you want to the data anyway. It'd be trivial to strip out all that stuff, and if EOT takes off, I'm sure you'll be able to find such utilities all over the place. Rather than DRM, it's more of an advisory flag - keeping the honest people honest, and the slightly mischievous people can read the spec, and write the trivial remover program; or remove the check from $browser.
It's even more interesting to note that there's actually no DRM in the submitted spec - there's a field (at a fixed location, which you can zero out if you really want to) that gives a machine-readable license statement, and, for some (legacy?) reason, an XOR-by-0x50 cipher, and the option of using subsetting to reduce font sizes at the expense of having to regenerate the font when the website changes. That's it. Nothing else.
There are two issues here, that slashdot combines, and neither of them are DRM. First, characters not used on the page may be dropped from the font to save space - this isn't DRM, just a bandwidth saving measure. This is why the EOT fonts, if subsetted, must be regenerated if your site changed - while it may be annoying, depending on the implementation, there are no restrictions on the renderer, nor is this a required portion of the spec.
Second, there are embedding flags (EOT spec, 4.1). These are essentially a machine-readable copyright and license statement - it is absolutely trivial to manipulate this field. You could do it in a few dozen lines of code in the programming language of your choice, with no need to reverse engineer, drag out keys, whatever.
In short, nothing to see here. This slashdot article makes a big deal out of absolutely nothing.
Good luck linking a binary blob into the rendering engine in a way that doesn't allow you to slurp it out by modifying said rendering engine. Moreover, what possible benefit would Mozilla have from such an action? It would just burn bridges, with no real benefit.
It's all moot anyway though - if anyone actually bothers to read the spec, there's no DRM - you only need to regenerate it because the fonts are compressed by removing characters not used by the page in question (which is a reasonable idea, although possibly a bit annoying depending on the implementation). There are bits controlling embedding permissions, but this is trivial to work around. They're better thought of as a machine-readable license statement; it's trivial to read them, replace them, ignore them, whatever, all in a nicely GPLv3'd debian package consisting of a few dozen lines of C code if you want.
Simply put, Firefox now has enough audience that web designers can't ignore it. Either EOT can be implemented with open-source code in firefox, which means its decryption scheme will be right out there in the open (and firefox can even simply fail to implement the DRM portions) - or it will only work in IE, which means it's unlikely to be used anywhere it matters.
It's not unprecedented. But Commodork was actually good.
This filesystem is meant for embedded devices with Flash storage that presents itself as a portion of physical memory - essentially, it helps the kernel avoid the overhead of copying from Flash to RAM when you can just run it out of Flash.
XiP has been supported in other filesystems, this is more like a small improvement - nothing to get excited about. Moreover, you won't see it in use in any desktops - this filesystem is read-only; more like an archive format understood by the kernel.
More useful discussion can be found at kerneltrap.