FWIW, Bing is actually used more than you think in China. Not because it's good, but because domestic solutions (Baidu) are crap for anything not in Mandarin, and all the other search engines (Google, Yahoo, Duckduckgo,...) are blocked.
Mmm, I'm wondering how long it'll take before some kind of malware keeps its keys in-memory, so when you shut down the PC or kill the process the entire HD gets un-decryptable...
The designers of the Clipper chip (http://en.wikipedia.org/wiki/Clipper_chip) had just about the same method in mind: encryption for the users, with an independent organization knowing the master keys and being able to hand over session keys to decode communications to government institutions. It was actually the reason why PGP etc were invented.
We have a similar situation here: the gov wants to have the keys to encrypted machines. Theoretically, the same arguments can be brought up again: it's bad because the keys may leak, it weakens the encryption because there's another set of keys that can be bruteforced or found in a smarter way, but it's also pretty ineffective: the phones that allow people messing around in their systems (Jolla, Ubuntu phones, rooted Androids) will just have third-party, non-gov-approved encryption in them and criminals (and people not really comfortable with NSA snooping) will subsequently use these.
...they're going to dig for copper cabling that's thousands of years old, to prove they had a phone network before everyone else. When they don't find any, they'll conclude the only reason for that can be that they moved to mobile phones even back then!
FYI: According to the internet, the joke in question was: 'What's the difference between Mark Bridger and Santa Claus? Mark Bridger comes in April.'...yeah.
For playing a movie - maybe. For actually burning a torrent - fair enough... if that is the _only_ thing that happens.
The point is that multiple accesses is going to delay the drive by a huge amount. If you want to, say, copy that Linux iso to your NAS at the same time as someone is playing a movie, the tape drive is going to have to move between the locations of the two files, which is going to wreck the access times, as I stated. Torrents are worse: you're downloading from / uploading to a bunch of other computers, all wanting to read from or write to a different location in the file. Again, this means moving between locations and the resulting huge access times.
You may be able to alleviate the process by putting a SSD or HD as cache in between, but I'm not sure if there's off-the-shelf software to do that, and I'm not even sure if that's going to work comfortably. Besides, if you're going to put a SSD or HD in between, why not just use that?
The big disadvantage of tapes is that it has long seek times. Not 'long' as in a few times that of a hard disk, but 'long' as in: can take a full minute to do. Access of multiple files on a normal HD is done by reading a meg of the first file, then seeking to the second file and reading a meg, going back to the first file and reading a meg etc. On a tape drive, even when the seek time is only, say, 10 seconds, you'd get a total throughput of 100K/sec that way. And I'm not even talking about the havoc that using it for storage of torrent files wreaks on it: that's a random-access process if I ever saw one, and the seek times on tape would kill your bandwidth very quickly, and probably your tapes too (because of wear&tear).
The device can detect the _way_ tou touch it (one finger, complete hand,...) but not _where_ you touch it, so it's not a touchscreen per se, more of a more-intelligent touch switch. I admire the way they made it from fairly simple components: I built my own prototype working in the same fashion in about one evening after reading their docs: http://spritesmods.com/?art=engarde
I think Andrew Ng had an easier job: machine learning is a course with a curriculum that's better defined than the almost all-encompassing AI class. That's why I had the idea the AI course sometimes jumped from subject to subject, while the ML class was more building up to something. I agree the ML class was easier to follow, I don't think it's because of the teacher, though: swap Andrew and Sebastian/Peter and I think you'd gotten the same result. Aside from that, I immensely enjoyed both courses (enough to enroll in one of Udacities courses as soon as it was announced), so they both did an excellent job.
Sixpack for the win:) Nope, I didn't see the pacman machine, though I have heard about it. When I obtained an Atari from somewhere, I was inspired by the story and put it in the hallway with a copy of Xenon 2 permanently plugged in. Good times were had, until the machine broke. A bit later we got a PC next to the living room TV to watch all the creative-commons-licensed movies shared around the campus on (*cough*) and we played Puzzle Bobble completely to death. So yeah, the game , if anything, was an inspiration for more gaming:)
The PC connected to the TV still runs a menu on top of X that's written by me. I also automated the beer-list to a LCD+touchscreen thing, and while it's made out of bad soldering joints and gaffer tape, somehow that contraption still manages to survive.
From what I know of flash, the 'bad bits' aren't repeatedly bad. The bad-sector-swap-out-routine in most flash drives and USB sticks will actually swap out a sector after a single read that can't be ECC-corrected, but that doesn't mean all the bits in the sector can't be written correctly ever again.
For example, in this article (IEEExplore, so paywalled for you, sorry) a generic NAND flash chip has been tested for bit-error-rates. In the 5K write cycles after an average bit has failed, it only failed to be written correctly 4 times more. That would mean that a single erase-rewrite cycle would write the complete sector without any bit errors 99% of the time: to find 'most' of the bad bits, the sector would have to be rewritten 1000s of times every time the software would want to check the fingerprint.
Not only would that take a fair amount of time, it would also introduce new failed bits. That would mean the ID of the flash chip can only be checked so many times beffore the complete sector goes bad.
It indeed is packed BCD. Some processors of that time have special instructions for that kind of notation, which makes calculating with them not much more difficult than normal binary. (Dunno if the 6502c has these kinds of opcodes, though; the Z80 for example does.) The advantage is that it makes blitting to screen really easy: instead of constantly dividing by 10, which is a processor-intensive task, you could just bitshift the number, which is much easier.
2600/7800 DEVELOPMENT KIT<br> CARE AND FEEDING INSTRUCTIONS<br> [...] Feel free to telephone John Feagans at Atari (U.S.) at area code (408) 745-xxxx any time you have a question about using the software. He wrote the download program and the transfer rom code. He's the one who did not write any support documentation to go with his software.
* From the base sw: CPX #1 ;HACK: WE STOP AT 1 BEQ SELRTS INX ;BIGGER HACK: PUSH X INTO RANGE. LDA ZHACKMOD+2,X ;BIGGEST HACK: TABLE LOOKUP NEXT MODE.
* Ofcourse, we have explicit words: CMP #$FF ;SEE IF ANY INPUT BEQ FUCKYOU JMP GOTOSEL ;GO TO SELECT MODE FUCKYOU BIT INPT4 ;LOOK AT FIRE BUTTON INPUT BMI ATIT4
LDA #0 ;ENOUGH TIME HAS ELAPSED TO ALLOW CAPS STA $1 ;TO DISCHARGE SO CONTINUE FUCKING WITH LDA #$14 ;IO HARDWARE
STA AUDC0,X ;GO POUND SAND IN YOUR ASS
* Citizen Kane anyone? LDA INPT0,Y ;THESE FOUR LINES MUST BE INCLUDED IN ;THE FINAL VERSION AND INPT1,Y ;REMEMBER BMI FUCKBAR ;REMEMBER,. .., ROSEBUD
* In Galaga, at 'a boss hit': JSR ABOSSHIT ; HOW YOU PRONOUNCE IT IS YOUR OWN ;BUSINESS
* Liek wtf? * GROUND TARGET SECRET CODES (SSHHHH!) * 0 regular dome logram * 1 regular pyramid barra * 2 detector dome zolbak (and your mama, too)
*And finally, an original comment which couldn't be more to the point in 2009: *PROGRAMMERS BEWARE: THIS CODE IS OLD AND VERY UGLY! TAMPER AT YOUR OWN RISK
It looks like Hattrick is written mostly in Forth btw. I personally didn't know they wrote games in that language!
The idea of XiP is that if you have a piece of storage that's directly accessible as memory to the CPU (e.g. a piece of old-school ROM, NOR-flash, battery-backed RAM, or phase-change memory), the CPU can just execute a program directly from there instead of first copying it to RAM and executing it there. Storing programs in this memory so they can be executed is something that normal filesystems can't do per default, and that's why this is something interesting: You'll still need RAM for the data parts of the program, but the programs and libraries themselves can remain on disk without taking up precious RAM.
Can you imagine an Acer laptop that can partially recharge the battery while it's running?
Nope. Can't say I can. You're free to patent it though, though I think you'd be having some trouble getting the patent office to accept your patent...
You're telling this as a joke, but actually there's caching software available that does exactly that for Linux. According to your previous usage patterns, it'll try to guess what programs you will start up and pre-load them in memory.
For your information: on most open-source-ish hardware, you have the option of soldering a small dongle (which isn't difficult) to the JTAG-port of your device. You can then flash a small bootloader(-ish program) to the device which you then can use to re-flash it. That fixes the most disastrous of misflashes: when somehow the bootloader gets destroyed. Normally, this isn't needed: in opensource-based stuff a flash usually leaves the bootloader intact, so you can always try a reflash, no matter how destroyed the OS-image itself is. So in this case 'the l33t dudes in #linux' actually would be able to help you.
...It seems to be a sort of script which can output various comments and sourcecode lines in a certain order. I think the technical part is nicely done: in this way, you can get a neat walkthrough of how the code works with the up-to-date, real code interspersed with the documentation. For example: if the routine can use a certain macro, the script can be written to explain the macro directly from the header file in which is defined. That's nice, I always hated to look them up myself. (So, for the people who didn't get this before, it is not a real text adventure, it's just that some passages are written realy adventure-ey.)
Apart from the technical details, the documentation itself is nicely done, too: while the stuff that's discussed is kinda hard to digest, the nuggets of humour that can be found made me want to find the rest too. I agree that these aren't really necessary if you, for example, are paid to create a patch to the lguest-system, but it can be useful for people who just want to mess with the code: easier-to-read documentation will make less of these people give up and more, hopefully interesting, patches will be developed.
If any, it was a nice way to learn about a basic virtualisation-implementation. I for one am a bit more knowledgable after reading it.
Slashdot Mirror
FWIW, Bing is actually used more than you think in China. Not because it's good, but because domestic solutions (Baidu) are crap for anything not in Mandarin, and all the other search engines (Google, Yahoo, Duckduckgo, ...) are blocked.
Mmm, I'm wondering how long it'll take before some kind of malware keeps its keys in-memory, so when you shut down the PC or kill the process the entire HD gets un-decryptable...
A W2 tax from shows the amount of taxes withheld from your paycheck. It's used to file your taxes.
https://turbotax.intuit.com/ta...
I presume the article refers to this data. Does anyone have any idea what the scammers can do with this?
The designers of the Clipper chip (http://en.wikipedia.org/wiki/Clipper_chip) had just about the same method in mind: encryption for the users, with an independent organization knowing the master keys and being able to hand over session keys to decode communications to government institutions. It was actually the reason why PGP etc were invented.
We have a similar situation here: the gov wants to have the keys to encrypted machines. Theoretically, the same arguments can be brought up again: it's bad because the keys may leak, it weakens the encryption because there's another set of keys that can be bruteforced or found in a smarter way, but it's also pretty ineffective: the phones that allow people messing around in their systems (Jolla, Ubuntu phones, rooted Androids) will just have third-party, non-gov-approved encryption in them and criminals (and people not really comfortable with NSA snooping) will subsequently use these.
...they're going to dig for copper cabling that's thousands of years old, to prove they had a phone network before everyone else. When they don't find any, they'll conclude the only reason for that can be that they moved to mobile phones even back then!
FYI: According to the internet, the joke in question was: ...yeah.
'What's the difference between Mark Bridger and Santa Claus? Mark Bridger comes in April.'
For playing a movie - maybe. For actually burning a torrent - fair enough... if that is the _only_ thing that happens.
The point is that multiple accesses is going to delay the drive by a huge amount. If you want to, say, copy that Linux iso to your NAS at the same time as someone is playing a movie, the tape drive is going to have to move between the locations of the two files, which is going to wreck the access times, as I stated. Torrents are worse: you're downloading from / uploading to a bunch of other computers, all wanting to read from or write to a different location in the file. Again, this means moving between locations and the resulting huge access times.
You may be able to alleviate the process by putting a SSD or HD as cache in between, but I'm not sure if there's off-the-shelf software to do that, and I'm not even sure if that's going to work comfortably. Besides, if you're going to put a SSD or HD in between, why not just use that?
The big disadvantage of tapes is that it has long seek times. Not 'long' as in a few times that of a hard disk, but 'long' as in: can take a full minute to do. Access of multiple files on a normal HD is done by reading a meg of the first file, then seeking to the second file and reading a meg, going back to the first file and reading a meg etc. On a tape drive, even when the seek time is only, say, 10 seconds, you'd get a total throughput of 100K/sec that way. And I'm not even talking about the havoc that using it for storage of torrent files wreaks on it: that's a random-access process if I ever saw one, and the seek times on tape would kill your bandwidth very quickly, and probably your tapes too (because of wear&tear).
The device can detect the _way_ tou touch it (one finger, complete hand, ...) but not _where_ you touch it, so it's not a touchscreen per se, more of a more-intelligent touch switch. I admire the way they made it from fairly simple components: I built my own prototype working in the same fashion in about one evening after reading their docs: http://spritesmods.com/?art=engarde
I think Andrew Ng had an easier job: machine learning is a course with a curriculum that's better defined than the almost all-encompassing AI class. That's why I had the idea the AI course sometimes jumped from subject to subject, while the ML class was more building up to something. I agree the ML class was easier to follow, I don't think it's because of the teacher, though: swap Andrew and Sebastian/Peter and I think you'd gotten the same result. Aside from that, I immensely enjoyed both courses (enough to enroll in one of Udacities courses as soon as it was announced), so they both did an excellent job.
Sixpack for the win :) Nope, I didn't see the pacman machine, though I have heard about it. When I obtained an Atari from somewhere, I was inspired by the story and put it in the hallway with a copy of Xenon 2 permanently plugged in. Good times were had, until the machine broke. A bit later we got a PC next to the living room TV to watch all the creative-commons-licensed movies shared around the campus on (*cough*) and we played Puzzle Bobble completely to death. So yeah, the game , if anything, was an inspiration for more gaming :)
The PC connected to the TV still runs a menu on top of X that's written by me. I also automated the beer-list to a LCD+touchscreen thing, and while it's made out of bad soldering joints and gaffer tape, somehow that contraption still manages to survive.
From what I know of flash, the 'bad bits' aren't repeatedly bad. The bad-sector-swap-out-routine in most flash drives and USB sticks will actually swap out a sector after a single read that can't be ECC-corrected, but that doesn't mean all the bits in the sector can't be written correctly ever again.
For example, in this article (IEEExplore, so paywalled for you, sorry) a generic NAND flash chip has been tested for bit-error-rates. In the 5K write cycles after an average bit has failed, it only failed to be written correctly 4 times more. That would mean that a single erase-rewrite cycle would write the complete sector without any bit errors 99% of the time: to find 'most' of the bad bits, the sector would have to be rewritten 1000s of times every time the software would want to check the fingerprint.
Not only would that take a fair amount of time, it would also introduce new failed bits. That would mean the ID of the flash chip can only be checked so many times beffore the complete sector goes bad.
It indeed is packed BCD. Some processors of that time have special instructions for that kind of notation, which makes calculating with them not much more difficult than normal binary. (Dunno if the 6502c has these kinds of opcodes, though; the Z80 for example does.) The advantage is that it makes blitting to screen really easy: instead of constantly dividing by 10, which is a processor-intensive task, you could just bitshift the number, which is much easier.
* From the devkit readmes:
;GO TO SELECT MODE ;LOOK AT FIRE BUTTON INPUT
;THESE FOUR LINES MUST BE INCLUDED IN ;REMEMBER ;REMEMBER,. . ., ROSEBUD
2600/7800 DEVELOPMENT KIT<br>
CARE AND FEEDING INSTRUCTIONS<br>
[...]
Feel free to telephone John Feagans at Atari (U.S.) at area code
(408) 745-xxxx any time you have a question about using the
software. He wrote the download program and the transfer rom
code. He's the one who did not write any support documentation
to go with his software.
* From the base sw:
CPX #1 ;HACK: WE STOP AT 1
BEQ SELRTS
INX ;BIGGER HACK: PUSH X INTO RANGE.
LDA ZHACKMOD+2,X ;BIGGEST HACK: TABLE LOOKUP NEXT MODE.
* Ofcourse, we have explicit words:
CMP #$FF ;SEE IF ANY INPUT
BEQ FUCKYOU
JMP GOTOSEL
FUCKYOU BIT INPT4
BMI ATIT4
LDA #0 ;ENOUGH TIME HAS ELAPSED TO ALLOW CAPS
STA $1 ;TO DISCHARGE SO CONTINUE FUCKING WITH
LDA #$14 ;IO HARDWARE
STA AUDC0,X ;GO POUND SAND IN YOUR ASS
* Citizen Kane anyone?
LDA INPT0,Y
;THE FINAL VERSION
AND INPT1,Y
BMI FUCKBAR
* In Galaga, at 'a boss hit':
JSR ABOSSHIT ; HOW YOU PRONOUNCE IT IS YOUR OWN
;BUSINESS
* Liek wtf?
* GROUND TARGET SECRET CODES (SSHHHH!)
* 0 regular dome logram
* 1 regular pyramid barra
* 2 detector dome zolbak (and your mama, too)
*And finally, an original comment which couldn't be more to the point in 2009:
*PROGRAMMERS BEWARE: THIS CODE IS OLD AND VERY UGLY! TAMPER AT YOUR OWN RISK
It looks like Hattrick is written mostly in Forth btw. I personally didn't know they wrote games in that language!
Maybe you can use a project I published recently: http://spritesmods.com/?art=minimalism
If anything, CramFS is readonly (think iso9660). This filesystem seems to be read/write, so that, if anything, is a big improvement.
The idea of XiP is that if you have a piece of storage that's directly accessible as memory to the CPU (e.g. a piece of old-school ROM, NOR-flash, battery-backed RAM, or phase-change memory), the CPU can just execute a program directly from there instead of first copying it to RAM and executing it there. Storing programs in this memory so they can be executed is something that normal filesystems can't do per default, and that's why this is something interesting: You'll still need RAM for the data parts of the program, but the programs and libraries themselves can remain on disk without taking up precious RAM.
The willingness of scientists to stretch a definition in order to gain more funds. s/(*)/nano-\1/g = more investors, it seems.
Can you imagine an Acer laptop that can partially recharge the battery while it's running? Nope. Can't say I can. You're free to patent it though, though I think you'd be having some trouble getting the patent office to accept your patent...
You're telling this as a joke, but actually there's caching software available that does exactly that for Linux. According to your previous usage patterns, it'll try to guess what programs you will start up and pre-load them in memory.
For your information: on most open-source-ish hardware, you have the option of soldering a small dongle (which isn't difficult) to the JTAG-port of your device. You can then flash a small bootloader(-ish program) to the device which you then can use to re-flash it. That fixes the most disastrous of misflashes: when somehow the bootloader gets destroyed. Normally, this isn't needed: in opensource-based stuff a flash usually leaves the bootloader intact, so you can always try a reflash, no matter how destroyed the OS-image itself is. So in this case 'the l33t dudes in #linux' actually would be able to help you.
With the difference that what The Pirate Bay does, actually is legal in Sweden.
...It seems to be a sort of script which can output various comments and sourcecode lines in a certain order. I think the technical part is nicely done: in this way, you can get a neat walkthrough of how the code works with the up-to-date, real code interspersed with the documentation. For example: if the routine can use a certain macro, the script can be written to explain the macro directly from the header file in which is defined. That's nice, I always hated to look them up myself. (So, for the people who didn't get this before, it is not a real text adventure, it's just that some passages are written realy adventure-ey.)
Apart from the technical details, the documentation itself is nicely done, too: while the stuff that's discussed is kinda hard to digest, the nuggets of humour that can be found made me want to find the rest too. I agree that these aren't really necessary if you, for example, are paid to create a patch to the lguest-system, but it can be useful for people who just want to mess with the code: easier-to-read documentation will make less of these people give up and more, hopefully interesting, patches will be developed.
If any, it was a nice way to learn about a basic virtualisation-implementation. I for one am a bit more knowledgable after reading it.