All I can say is that if your assembler looks like that, you're not using auto-registers and macro's properly. Now I'm a little rusty, and I can't think of a particular assembler that I've used recently, but:
Why are you trying to hide an e-mail address in your message? Trying to get someone you hate more spam? It might be a spam-trap, for training his/her spam filter.
I never actually look at the keyboard when I am typing, so I can see absolutely no advantage whatsoever to having bling keys.
For example if I want to draw a rectangle in gimp I type ctrl-r without thinking about it. I don't need to look at the keyboard for a stupid rectangle icon.
This keyboard is either for people who are cerebrally challenged or people who masturbate over their computer 24 hours a day because it has gold-plated heatsinks and neon underglow.
SPDIF and HDMI are PCM and pumped-pixel protocols, respectively, and they actually both tolerate a reasonable amount of signal degradation. Also both protocols have no error-correction, and you will see "sparklies" if your HDMI cable is introducing errors, where certain pixels are being corrupt, or if the cable is really fucked you will get weird pixel skew or the TV will sense that the signal is hosed and give up.
SPDIF is fairly conservative and you would have to use pretty crap/long cables before the bit-error-rate reached a point where you would even notice it, on the hand HDMI is very tight and damaged or crap cables will show errors on even short lengths of cable.
With compressed and error-corrected protocols such as DVB and SDI, what you have said is closer to the truth, as the signal errors will be corrected by the ECC and will not be noticed until enough errors are present that ECC cannot be used, at which point the equipment will start displaying weird garbage or the device will display a signal fault.
All digital signal pathways have a bit-error-rate and most protocols are designed to be tolerant to a certain level, in the case of HDMI, the standard is designed that conformant cables will result in a low enough BER, that any errors will be imperceptable, and as it is uncompressed, the worst case scenario of a single bit error would be a dropped frame, and the more likely result would be a single bright pixel.
Now when will they come out with MemoryTOP? Why does liferea eat more RES (30MB) than evolution (I mean evolution for god's sake!). And don't get me started on firefox. Reading slashdot or dailykos jumps firefox's RES to 75MB. Which apparently it will never willingly give up. And what's skype's excuse for eating 20MB of physical memory? [These stats are from top(1).] Is this a joke?
What is wrong with top for finding resident memory usage. You just press the less-than-key* three times, and it is sorted by resident memory usage.
* The symbol above comma on the keyboard,/. eats this character and won't display it.
Usually, at least for asymmetric ciphers, the high bit is set to guarantee that the number isn't easily factorisable. I don't know if there is relevance to a symmetric key, such as the AACS key.
In my experience VT102/linux/xterm terminal support is pretty much universally supported by things which use ssh. Did you try running xterm (I assume you have X11 installed)?
SSH actually (is supposed to) transmits the contents of the TERM environment before you get a shell. The only way I can see this not working is if their is no termcap/terminfo entry for your terminal, in which case it would be intuitive for me to set the TERM variable to either xterm, linux or vt102 and try my luck. If that didn't work then Mac terminal must be pretty silly (assuming it doesn't have a VT102 mode).
The difference is quite simple, the RIAA just wants to take all your money and have you locked up. They have no interest in tying you to a bon-fire and igniting you by pouring molten-lead in your mouth.
I know it's a subtle difference, but it's still there.
I haven't ever tried anything similar on Windows, but it would be trivially simple to have a script which SSH's to all workstations and configured the firewalls the same, or to have cron job fetch new firewall rules periodically over AFS or whatever. I haven't done either because at our site almost all machines are thin clients and so updating the image on the boot server and rebooting the clients is sufficient.
Your argument is totally spurious. NAT doesn't provide security aside from disallowing connections to originate from outside the network, this provides very little security, as most attack vectors on workstation PC's are via HTTP or email* which are both internally originated.
Once a machine has been compromised, it can make outward connections to anywhere it pleases (With just NAT), and can listen on any UDP port it wants to by sending packets out packets to bogus addresses (like STUN for SIP).
You are correct in stating that the outside network shouldn't be able to arbitrarily connect to your internal network, but likewise the internal network shouldn't be able to arbitrarily communicate with the world. This is trivially simple to do on both IPv6 and IPv4 networks and only someone truly incompetent would argue that IPv6 is bad because it doesn't have NAT.
Example:
The correct way to provide security on IPv4 (on Linux): iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -F iptables -A INPUT -s $ADMIN_HOST -d $INT_ADDR -i $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT iptables -P INPUT REJECT iptables -A OUTPUT -s $INT_ADDR -d $ADMIN_HOST -o $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT iptables -P OUTPUT REJECT iptables -P FORWARD REJECT echo 1 >/proc/sys/net/ipv4/ip_forward...(Commands for allowing acceptable connections follow)
On IPv6 (on Linux again):
ip6tables -P INPUT ACCEPT ip6tables -P OUTPUT ACCEPT ip6tables -F ip6tables -A INPUT -s $ADMIN_HOST -d $INT_ADDR -i $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT ip6tables -P INPUT REJECT ip6tables -A OUTPUT -s $INT_ADDR -d $ADMIN_HOST -o $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT ip6tables -P OUTPUT REJECT ip6tables -P FORWARD REJECT echo 1 >/proc/sys/net/ipv6/conf/all/forwarding # Maybe want to change this to only appropriate interfaces...(Almost identical commands for setting up acceptable IPv6 connections follow)
I imagine on other platforms it is just as simple or simpler to do the same. Some would argue that my method for allowing SSH is wrong, but it is convenient to allow all connections to the router (not the network) for a brief moment so that you still have ssh access in case anything goes fubar.
If anything IP Masquerading (The type of NAT you are probably referring to), makes firewalling harder, as it is more complicated to understand a packets path, and what address it has at a given position in the network.
*Think of all the Joe-sixpack machines behind ADSL or Cable routers which are already members of botnets.
It would be much easier if some kind person who takes the time to do all this would post a disk image that we could just copy directly to the hard drive. Except that posting instructions on how to do it is probably legal, whereas distributing Apple copyrighted software definitely isn't.
Extracting an encryption key from a block of memory which you *know* has the plaintext-key in it somewhere is trivially easy. All you do is rotate through all the memory (if a optimising compiler is used, it will even be on a word boundary), trying the key against some sample data (A bluray disk), until you get a valid data-stream and checksum. Even with 4GB of memory to search this would only take on the order of a couple of days.
As for extracting a memory slice from the PS3, you would need to either crack the hypervisor, or resort to using a rather pricey logic analyser which has enough channels and speed to log XDR transactions, and even then it doesn't help you if the key never leaves the cache.
I suppose if you really wanted to make a go of it, you could use a sample accurate cell simulator and a logic analyser to duplicate the functions of the periphery chips, though with current computing resources I doubt you could beat any timing checks (in 5-10 years it would be trivial).
I don't know anything about the Thai king and any great things he may have done which command such respect, though I have to assume that there are many great things, because to respect someone purely because of who they are is ridiculous, absurd and a quick road to fascism.
We have both the British queen and the Maori king in our country (New Zealand). I have very little respect for the queen over what I would grant anyone in a position of power out of courtesy. As for the Maori king, I know almost nothing about him, though I had great admiration for the late Maori queen.
Now I, personally, wouldn't ridicule or set out to offend either royal family, but I would quickly step up and defend anyone who was subject to such blatant and tyrannical fascism as this Swiss man apparently was. I also believe that any country which Ritually murders it's own citizens and those of other countries has real issues (Think Thailand/Indonesia/Singapore?/United States/Pakistan/etc), especially when such incidents can occur for such victimless crimes as drug (ab)use (including Thailand) or choice of religion (Pakistan, Iraq, Iran, etc).
For *any* people to claim ritual murder or tyrannical rule is ok because of cultural traditions, is as ridiculous as those who whould strap explosives to themselves and explode themselves in the name of [a certain primitive stone-age religion based on hate, hypocrisy and wars against non-believers], or, to give an example from my own country, those who are currently trying to justify beating and abusing their children because the [book of a certain other roman-age religion based on open kindness and veiled-hatred] says it is ok.
I can't see HDMI ever replacing 1394, as they are two completely different technologies for completely different purposes.
HDMI is a lossy (loss tolerant?) uncompressed digital transmission system for consumer displays with no error correction and no clock synchronisation, from which it would be quite difficult to reconstruct the exact same frame as was transmitted, it also (AFAIK) has no form of time-code or playback control system.
IEEE-1394 is a multi-peer bus architecture, which supports lossless transmission of framed data, with tight latency constraints. On of the useful protocols supported by IEEE-1394 is DV-1394 which allows a verbatim DV encoded AV stream to be transferred, frame-synchronised, between compatible devices and with AVC can also provide integrated seek control and TC's. It is also ubiquitous on high end workstations and is available on almost all prosumer and professional video cameras as well as digital cinema camera's (though 1394a doesn't possess the bandwidth for transferring DC in real-time).
To suggest that 1394 will be replaced by HDMI is like suggesting 20 years ago that YC video will be phased out because most (consumer) TV's only have composite or RF.
If it wasn't for the enormous installed base I might accept the notion that DV1394 would be replaced by HD-SDI, but to suggest that it would be replaced by HDMI is ludicrous. I have noticed a trend in that a lot of new pro camera's are including GigE, especially the ones using random access media (XDCAM, others).
I'd also like to note that I haven't seen any editing equipment or computer video grabbers which will accept an HDMI input, as opposed to the countless systems supporting both HD-SDI and 1394.
The GP's point stands. The registry is no more vulnerable than any number of Unix config files. An extra newline in/etc/password will cause the same problem. Firstly, there is no such file/etc/password, it is/etc/passwd since K&R didn't like typing and skimped on letters.
Secondly, I just tested this and it is completely untrue. extra newlines have absolutely no affect on the functioning of/etc/passwd in a linux-pam system.
Thirdly, transparent human readable and logically laid-out config files in/etc are much easier to diagnose and fix than an arbitrary (and slow) binary registry where the typical entry is something like "0x67386768787ab7aab87b78cd87687" and the key is "GRPAccountMaskFoo" (made up). Even when you take into account that files in/etc don't have any uniform format.
Sadly, some unix developers are oblivious to this simple truth, and are intent at re-creating the windows registry and COM *glares at Gnome developers*.
Heck, I still find myself programming machines (well uC's) with less than 2K of ram, some of them only have 256 bytes of ram (excluding.text being not RAM but (EE)-PROM).
The fact that the vast majority of computers don't run any operating system seems to be completely over most peoples heads. Including the many computers inside a PC, such as the HDD's internal controller or the 4/8-bit system instrumentation controller.
Slashdot Mirror
For the record:
I didn't mean to imply that comments are bad, just that using sensible names in assembler is just as important as any other language.
All I can say is that if your assembler looks like that, you're not using auto-registers and macro's properly. Now I'm a little rusty, and I can't think of a particular assembler that I've used recently, but:
.offset 0x6860686
#define total r1
#define item_value r2
#define items r3
#define count r4
sum:
mov item_value, @items
addd items, -4
addd total, item_value
decd count
cmp count
jnz sum
Reads better than:
mov r2, @r3
addd r3, -4
addd r1, r2
decd r4
cmp r4
jnz 0x6860686
(Note this isn't any particular assembler for any particular architechture, but I'm sure you can get the gist of what it does).
Uh.
MP3 Isn't lossless.
AAC isn't either.
Try Again.
I imagine it is slightly faster than JVM-JIT, but that is probably not a huge advantage to the kind of applications this is likely to target.
Intellectual Property does have one defined meaning, in one specific industry, Electronics design.
An implementation of a circuit is covered by Intellectual property protection that is not Copyright or Patent, but more a design rights license.
If you didn't call it IP, what would you call it (considering everyone understands the exact meaning of IP in this context).
In general using the phrase "Intellectual Property" is wrong, but when it comes to semiconductors I believe it to be the only correct name.
SO
FUCKING
WHAT.
I never actually look at the keyboard when I am typing, so I can see absolutely no advantage whatsoever to having bling keys.
For example if I want to draw a rectangle in gimp I type ctrl-r without thinking about it. I don't need to look at the keyboard for a stupid rectangle icon.
This keyboard is either for people who are cerebrally challenged or people who masturbate over their computer 24 hours a day because it has gold-plated heatsinks and neon underglow.
LAME.
No.
SPDIF and HDMI are PCM and pumped-pixel protocols, respectively, and they actually both tolerate a reasonable amount of signal degradation. Also both protocols have no error-correction, and you will see "sparklies" if your HDMI cable is introducing errors, where certain pixels are being corrupt, or if the cable is really fucked you will get weird pixel skew or the TV will sense that the signal is hosed and give up.
SPDIF is fairly conservative and you would have to use pretty crap/long cables before the bit-error-rate reached a point where you would even notice it, on the hand HDMI is very tight and damaged or crap cables will show errors on even short lengths of cable.
With compressed and error-corrected protocols such as DVB and SDI, what you have said is closer to the truth, as the signal errors will be corrected by the ECC and will not be noticed until enough errors are present that ECC cannot be used, at which point the equipment will start displaying weird garbage or the device will display a signal fault.
All digital signal pathways have a bit-error-rate and most protocols are designed to be tolerant to a certain level, in the case of HDMI, the standard is designed that conformant cables will result in a low enough BER, that any errors will be imperceptable, and as it is uncompressed, the worst case scenario of a single bit error would be a dropped frame, and the more likely result would be a single bright pixel.
Then there are those of us who remember when 1 gigabyte was considered a lot of storage. And those that remember when 1 Megabyte was a lot of storage.
What is wrong with top for finding resident memory usage. You just press the less-than-key* three times, and it is sorted by resident memory usage.
* The symbol above comma on the keyboard,
Usually, at least for asymmetric ciphers, the high bit is set to guarantee that the number isn't easily factorisable. I don't know if there is relevance to a symmetric key, such as the AACS key.
Small problem though:
There is no way in fuck you can store 2^128 * 17 bytes. I don't even think there is enough entropy on earth to enocde that much information.
In my experience VT102/linux/xterm terminal support is pretty much universally supported by things which use ssh. Did you try running xterm (I assume you have X11 installed)?
SSH actually (is supposed to) transmits the contents of the TERM environment before you get a shell. The only way I can see this not working is if their is no termcap/terminfo entry for your terminal, in which case it would be intuitive for me to set the TERM variable to either xterm, linux or vt102 and try my luck. If that didn't work then Mac terminal must be pretty silly (assuming it doesn't have a VT102 mode).
The difference is quite simple, the RIAA just wants to take all your money and have you locked up. They have no interest in tying you to a bon-fire and igniting you by pouring molten-lead in your mouth.
I know it's a subtle difference, but it's still there.
Energy is actually measured in Joules, unless you are an energy billing company (including service industries and generators).
Yes but how wide is the -20dB noise envelope on your blue led?
I'm guessing it would probably be greater than the frequency that this oscillator is running.
I haven't ever tried anything similar on Windows, but it would be trivially simple to have a script which SSH's to all workstations and configured the firewalls the same, or to have cron job fetch new firewall rules periodically over AFS or whatever. I haven't done either because at our site almost all machines are thin clients and so updating the image on the boot server and rebooting the clients is sufficient.
Your argument is totally spurious. NAT doesn't provide security aside from disallowing connections to originate from outside the network, this provides very little security, as most attack vectors on workstation PC's are via HTTP or email* which are both internally originated.
...(Commands for allowing acceptable connections follow)
...(Almost identical commands for setting up acceptable IPv6 connections follow)
Once a machine has been compromised, it can make outward connections to anywhere it pleases (With just NAT), and can listen on any UDP port it wants to by sending packets out packets to bogus addresses (like STUN for SIP).
You are correct in stating that the outside network shouldn't be able to arbitrarily connect to your internal network, but likewise the internal network shouldn't be able to arbitrarily communicate with the world. This is trivially simple to do on both IPv6 and IPv4 networks and only someone truly incompetent would argue that IPv6 is bad because it doesn't have NAT.
Example:
The correct way to provide security on IPv4 (on Linux):
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -A INPUT -s $ADMIN_HOST -d $INT_ADDR -i $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT
iptables -P INPUT REJECT
iptables -A OUTPUT -s $INT_ADDR -d $ADMIN_HOST -o $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT
iptables -P OUTPUT REJECT
iptables -P FORWARD REJECT
echo 1 >/proc/sys/net/ipv4/ip_forward
On IPv6 (on Linux again):
ip6tables -P INPUT ACCEPT
ip6tables -P OUTPUT ACCEPT
ip6tables -F
ip6tables -A INPUT -s $ADMIN_HOST -d $INT_ADDR -i $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT
ip6tables -P INPUT REJECT
ip6tables -A OUTPUT -s $INT_ADDR -d $ADMIN_HOST -o $INT_INTF -p tcp --dport $SSH_PORT -j ACCEPT
ip6tables -P OUTPUT REJECT
ip6tables -P FORWARD REJECT
echo 1 >/proc/sys/net/ipv6/conf/all/forwarding # Maybe want to change this to only appropriate interfaces
I imagine on other platforms it is just as simple or simpler to do the same. Some would argue that my method for allowing SSH is wrong, but it is convenient to allow all connections to the router (not the network) for a brief moment so that you still have ssh access in case anything goes fubar.
If anything IP Masquerading (The type of NAT you are probably referring to), makes firewalling harder, as it is more complicated to understand a packets path, and what address it has at a given position in the network.
*Think of all the Joe-sixpack machines behind ADSL or Cable routers which are already members of botnets.
Extracting an encryption key from a block of memory which you *know* has the plaintext-key in it somewhere is trivially easy. All you do is rotate through all the memory (if a optimising compiler is used, it will even be on a word boundary), trying the key against some sample data (A bluray disk), until you get a valid data-stream and checksum. Even with 4GB of memory to search this would only take on the order of a couple of days.
As for extracting a memory slice from the PS3, you would need to either crack the hypervisor, or resort to using a rather pricey logic analyser which has enough channels and speed to log XDR transactions, and even then it doesn't help you if the key never leaves the cache.
I suppose if you really wanted to make a go of it, you could use a sample accurate cell simulator and a logic analyser to duplicate the functions of the periphery chips, though with current computing resources I doubt you could beat any timing checks (in 5-10 years it would be trivial).
I don't know anything about the Thai king and any great things he may have done which command such respect, though I have to assume that there are many great things, because to respect someone purely because of who they are is ridiculous, absurd and a quick road to fascism.
We have both the British queen and the Maori king in our country (New Zealand). I have very little respect for the queen over what I would grant anyone in a position of power out of courtesy. As for the Maori king, I know almost nothing about him, though I had great admiration for the late Maori queen.
Now I, personally, wouldn't ridicule or set out to offend either royal family, but I would quickly step up and defend anyone who was subject to such blatant and tyrannical fascism as this Swiss man apparently was. I also believe that any country which Ritually murders it's own citizens and those of other countries has real issues (Think Thailand/Indonesia/Singapore?/United States/Pakistan/etc), especially when such incidents can occur for such victimless crimes as drug (ab)use (including Thailand) or choice of religion (Pakistan, Iraq, Iran, etc).
For *any* people to claim ritual murder or tyrannical rule is ok because of cultural traditions, is as ridiculous as those who whould strap explosives to themselves and explode themselves in the name of [a certain primitive stone-age religion based on hate, hypocrisy and wars against non-believers], or, to give an example from my own country, those who are currently trying to justify beating and abusing their children because the [book of a certain other roman-age religion based on open kindness and veiled-hatred] says it is ok.
I can't see HDMI ever replacing 1394, as they are two completely different technologies for completely different purposes.
HDMI is a lossy (loss tolerant?) uncompressed digital transmission system for consumer displays with no error correction and no clock synchronisation, from which it would be quite difficult to reconstruct the exact same frame as was transmitted, it also (AFAIK) has no form of time-code or playback control system.
IEEE-1394 is a multi-peer bus architecture, which supports lossless transmission of framed data, with tight latency constraints. On of the useful protocols supported by IEEE-1394 is DV-1394 which allows a verbatim DV encoded AV stream to be transferred, frame-synchronised, between compatible devices and with AVC can also provide integrated seek control and TC's. It is also ubiquitous on high end workstations and is available on almost all prosumer and professional video cameras as well as digital cinema camera's (though 1394a doesn't possess the bandwidth for transferring DC in real-time).
To suggest that 1394 will be replaced by HDMI is like suggesting 20 years ago that YC video will be phased out because most (consumer) TV's only have composite or RF.
If it wasn't for the enormous installed base I might accept the notion that DV1394 would be replaced by HD-SDI, but to suggest that it would be replaced by HDMI is ludicrous. I have noticed a trend in that a lot of new pro camera's are including GigE, especially the ones using random access media (XDCAM, others).
I'd also like to note that I haven't seen any editing equipment or computer video grabbers which will accept an HDMI input, as opposed to the countless systems supporting both HD-SDI and 1394.
You do realise you can access IDE ATAPI CD writers as ATA:whatever , and scan for them with "cdrecord dev=ATA: -scanbus".
The fact that you can use incorrect syntax to access the exact same device doesn't seem to buy anything.
Secondly, I just tested this and it is completely untrue. extra newlines have absolutely no affect on the functioning of
Thirdly, transparent human readable and logically laid-out config files in
Sadly, some unix developers are oblivious to this simple truth, and are intent at re-creating the windows registry and COM *glares at Gnome developers*.
Heck, I still find myself programming machines (well uC's) with less than 2K of ram, some of them only have 256 bytes of ram (excluding .text being not RAM but (EE)-PROM).
The fact that the vast majority of computers don't run any operating system seems to be completely over most peoples heads. Including the many computers inside a PC, such as the HDD's internal controller or the 4/8-bit system instrumentation controller.