Not only do you need to translate strings (and as you say, use real live translators to do it, at least for anything you care about), but you also need to deal with formatting order (especially in printf-like statements).
In many languages, you have strings like this: "You, %s, owe us %s dollars." that are used with formatted print statements such as printf() that make assumptions based on ordering: printf(get_locale_string(you_owe_us_string),name,l ocal_money_string(amount)).
In another language, the ordering of name and amount may NOT be the same. You really need to use an indexed string inserter like this: "You, %1, owe us %2 dollars." This way a localized string could have %2 first, then %1.
In Scala (http://www.scala.com/) we handled it this way. Very effective (so far as it goes).
Another important thing: French is not just French, English is not just English. There's US English and British English; French-Canadian and French, etc. And that's ignoring things like date ordering, monetary issues, etc.
DNS and the web have made all names/trademarks "global" be default. You can't have 27 Acme Cleaners scattered across the nation all with acmecleaners.com/biz/etc. And as others have pointed out, the whole reason for the problem is that people search for the website of a known company by typing acmecleaners.com and hoping it resolves to the "right" acme cleaners; i.e. they use DNS as a search/indexing tool. I've been guilty of this myself, though I've mostly taken to using Google - far more likely to get the right domain by typing a company name (and sometimes a little other info) there.
This leads to lots of angst and lawsuits over domains (especially for more "generic" ones), consumer confusion, etc.
Solutions (ok, not really, but ways to minimize the problem):
1) Choose a relatively unique name when starting a business - and search for it, not just on the web but in yellow pages/infospace, etc. (Not an option for existing ones.) 2) Advertise and constantly reinforce the URL for your business. 3) Make sure if someone looks for you in google/yahoo/etc with a reasonable search string they can find you. Don't game the system (try to make all Acme Cleaners searches go to you), but make it useful for consumers (try to get Acme Cleaners Boston to go to you - reinforce that on your main page). 4) if you have a name "foobar", and foobar.com is take, find something else similar that's easy to remember. I work for Worldgate Communications. "worldgate.com" was taken before we started, so our domain is "wgate.com" - and it doesn't hurt that much. 5) Don't spend huge amounts of time and trouble trying to lock up every variant TLD. The extra traffic from those isn't huge, and is less if you do the things above.
It doesn't have to return in constant time, but it does have to return in time invariant (or very close to) on the key.
This class of attack isn't new. The AES selection people considered it but didn't think much about the cache line issue (or the sbox table lookup time issue and how it interacts with caches).
The class of attack of using CPU load/switch latency to pass information from a secure process to an insecure one dates back at least to the mid or early 80's (first time I read about it at RPI).
Note that some of these mechanisms don't require processes running; they involve time to respond to a request that requires cryptographic processing (encrypt/decrypt). The AES paper shows this attack can work over a network (though at severely reduced leakage rates). This also implies that for the network leakage case, you don't have to go to the same levels of extremes before the leakage rate becomes on the order of the brute-force cracking time, and thus a wash. In addition, if it's only network attacks you're protecting against, you merely have to guarantee that the packet response time is approximately constant (or doesn't vary with the key data), so you can "hold" responses until (say) 100ms have elapsed while doing other processing.
This issue exists with AES implementations as well (search for AES SBOX cache timing on google). The AES vulnerability is, if anything, more worrying in a way. It can be made to be constant-time, but at a serious cost in performance.
Here's another option: since this vulnerability depends on using the L1/L2 cache states to ferret out information, remove that from consideration. When processing an RSA (etc) key, have the code temporarily lock out context switches, AND have it take a fixed period of time to compute the result (or portion of the result), followed by flushing the cache. No data is left in the cache to analyze. The execution time of the code is fixed, so no dat leaks there. You don't have to make the algorithm a constant-time calculation if you can pad it at the end to the maximum (or close enough to the theoretical maximum that there's no true information leakage in practice). This helps avoid the potentially very slow algorithms that are truely constant-time. And flushing the cache at the end of each (portion of the) calculation removes that as a leak. (You need to flush it before waiting for the allocated time to elapse, note, and include max flush time in your calculation, and if possible factor into your calculation possible interrupt effects.)
A pain? yes. Requires extensive mods to crypto algorithm implementation? Yes (though perhaps not to the core calculation.) Requires OS support? Almost certainly. Requires HW support? Would be helpful but probably not required. Loss of performance? Yes, though far lower than disabling HT I imagine in normal cases (when not decrypting/encrypting).
Also, some of the restrictions above can probably be eased if the crypto algorithm is carefully designed and matched to the hardware.
Disclaimer: I am NOT a crypto geek! I have worked in processor and cache design, though.
I would assume their apps are dynamically linked against LGPL libs (if their apps directly use LGPL libs at all).
Realize their "warning" that it won't work may not be true in practice. (Though it violating your warrantee probably is true.) If you modify a lib and it accidentally deletes all your saved programs, it's not their problem.
More to the point, I suspect the anti-service-theft code makes it effectively impossible to replace a library - there's probably a disk and/or memory checksum that considers any change that isn't signed with their private key to be an attempt to hack the unit and steal service. This checksum process probably is outside of the app that uses LGPL (for example, burned in ROM/flash within the processor or chipset). So you can modify the library or recompile linux, etc and replace it - but the unit will probably simply fail to even attempt to start. Or the code is encrypted on the disk with a key you don't have access to.
LGPL has limits - which is part of why Stallman didn't like it to begin with. GPL has limits too; many of these things I mentioned above apply to GPL code as well.
IANAL, etc. Yes, some of these things may (depending on your point of view) violate the spirit of the GPL/LGPL. But be careful trying to decide whether they've violated the legalities of a GPL/LGPL copyright; it's not so simple, especially with devices with firmware (flash, disk or otherwise). It does sound like they're following the legal requirements of the GPL/LGPL as needed. The anti-hacking code in the processor/flash/disk probably will make it impossible to modify the code in the actual unit (and have it receive service!) You may be able to replace the code on the unit and use the hardware. Getting it to then receive encrypted broadcasts and record/show them will probably not be possible.
Just my guess. I haven't even looked at what they released.
You're assuming it's a monolithic executable. I'm sure it's not. It's proprietary stuff running on top of (possibly modified and released) Linux, with some LGPL libs (released I'm sure with any mods) and some GPL executables that are part of Linux userspace.
No, MTS - Michigan Terminal System. Created at Michigan State I believe; ran there, Waterloo, RPI, and 8 or 10 other universities (maybe more). Used to run 100-175 users on a 370/3033 and later a 370/3091(?) 4-CPU system. At RPI, the main computing center (VCC, Voorhees Computing Center) was (and is) an old chapel, with 20' stained glass over the terminals.
VERY different than MVS.
Probably the only OS that came with a full PDP-8 simulator as a system command - and the PDP-8 simulator was used once to break the security of the OS. Really. A buffer-overrun attack.
Exactly - the author of this "test" made a bad assumption: fsync() (or rather the windows equivalent) means it's on the disk. Understandable, and once upon a time it was true in Unix. fsync() doesn't (that I know of) issue ATA sync commands, though.
I used to beta-test SCSI drives, and write SCSI and IDE drivers (for the Amiga). Write-caching is (except for very specific applications) mandatory for speed reasons.
If you want some performance and total write-safety, tagged queuing (SCSI or ATA) could provide that (with write caching turned off). You'll still give up some performance, since the a single-threaded write application/FS will wait for data to be on disk before continuing. If the FS/app writes (say) 3 chunks of data that fill a track, with write caching off and tagged queuing, it's probably a minimum of 3 rotations (probably more like 4.5 or more) to write the data. With write caching, it's minimum 1, more like average 1.5 rotations. With a LOT of pain, you could break the single-threadedness of this in some cases by not waiting for tagged write completions and reporting success, while marking the VM pages as copy-on-write or some equivalent so the app won't overwrite the data that you're still writing (or, you could only return success to the app/FS when the data has been sent to the drive, but before it reports success). This (in a way) moves the write cache into the disk driver and thus gives you control over it. Perf will still be lower than letting the drive do it, perhaps a lot lower in some cases.
If you want _real_ performance and safety, turn on write caching, and when you hit a "safety checkpoint", tell the drive to flush the write cache to disk. I don't currently believe that ATA or SCSI drives generally ignore that command - please provide links if you know differently. It's not a benchmarking advantage to subvert that unless the OS/app is using it - but maybe OS's are turning fsync()/etc into ATA/SCSI sync commands, and the drive makers are lieing.
On MTS (IBM mainframe OS used at universities in the 70's/80's and probably into the 90's) there was a bug where when process switching, the FP registers of the last process to run were stored in a world-readable page of memory. The RPI ACM used this to create an inter-process communication program -- actually a 'chat' program (MTS had no inter-process communication other than files at the time).
("Genius" tends to be used for people who can do things others can't, or can figure out things others are stumped by. In fact, it tends by definition to be linked to things that others will have trouble following even if they do try to document. I used the term very deliberately...)
Another thought is that the [1] should be changed. I'm guessing that you are referring to the second byte of the received packet, and using it as a flags field of some kind. If that is the case, why not go ahead and make a struct that represents the header layout, and reference the flags through a bitfield in the struct? If you do that,
(*curr)->GetPayload()[1] & FU_E_BIT
Becomes
(*curr)->header->flag_end_of_message
...which seems clearer to me.
There are actually a few reasons it's the way it is. First, the payload might not be aligned and so (given the compiler and CPU) using structure for access could fail to access the correct bit - even though it's a bitfield in a byte, the compiler will use a longword access to extract the bit no matter what you do (at least as far as I was willing to care about trying variation).
Not to say that some of what you say isn't reasonable. However, in this code, I don't want to hide what we're doing with the bits of the structure - this is an external (wire) interface, so at this level of the code I want to be explicitly concerned with the handling of the specific bits defined in the protocol. And the event loop is at a higher level; this is part of the equivalent to IsCompleteMessageAvailable().
Said "genius" programmer was in fact really really good at producing working, bug-free, very fast code, and doing complex projects others had totally failed at. But (as you mention) you wouldn't want anyone less skilled than he was working on it. And that person had better be an expert at deciphering undocumented code.
He was also the author of a very good book on x86 assembly optimization, which might explain something.
I worked with a programmer who disliked comments so much he'd remove them before looking at a function. Ok. So I wrote some code and he came to me and said "why do you have an empty else case?" I was puzzled, then realized that I'd written something like this:
else { /* we don't have to do anything in the else case because of x y and z */ }
where x y and z would be non-obvious to anyone who wasn't fully immersed in this code. He's run it through a filter that removed all comments. He was a genius programmer - but wrote code that almost no one else could ever maintain. Tons of reliances on edge conditions without comment, reuse of generically-named variables (1 and 2 character names), tricky (but efficient) algorithms. So far as I know, I was the only one there ever to manage to really grok his code, and that required days of immersing myself.
x = x++;// add one to x
is obviously not useful.
// Test FU_E (End bit) after FU_A/FU_B test! If there's a gap, do not consider // hitting the End bit a marker to stop - continue until we see another // packet/timestamp (in which case we return TRUE), or until we are // at the end of the buffer (in which case we return FALSE and keep // hoping to assemble it). if (((*curr)->GetPayload()[1] & FU_E_BIT) && !gap) break;// no error in fragment // if there's a gap we still won't return true unless // we find a non-fragment packet (or one from another fragment!)
This is an example of a useful comment - and yes, it has to be maintained if the line of source were to change. I chose that at random; there are better examples - such as explaining what the edge cases are (especially if not handled), and under what circumstances they would become relevant, and how they could be dealt with then.
Please excuse the incorrent indenting above; "<ecode>" doesn't work exactly like 'pre'
And if you lose your palmpilot (or it breaks), you need to get new passwords for everything, unless the data syncs to your PC (which it probably does). Which then makes it safe unless someone can keylog your PC - but you're probably toast if they do that anyways.:-)
They do have rights in this case - rights to what you wrote. If _they_ distribute the entire package including what you wrote, they have to comply with the license for the code you modified, which (if GPL) requires that they release the source including your mods. Effectively, they're the modifier of the package, not you.
If they don't distribute (use it internally, say), they do NOT have to make your mods public. And in many licenses, "public" means provide it to the people who buy the modified package.
They CAN patent things in the mods you wrote (some licenses may have something to say about distributing such code, and it wouldn't likely make it back into the source tree). They CANNOT patent things that were in the original code since neither you nor they invented them (duh).
This company CAN be sued by the rights holders of the original code. Their patent (if based on the code in the original project) will NOT be valid, but they can still file it and probably get granted. (If they knew it wasn't patentable or don't disclose the prior art, it can be overturned on that alone probably - if challenged.)
Sounds like a lawyer (or manager more likely) there knows employment law, but really doesn't know anything about copyright law and doesn't care.
Be very careful if you decide to "go public" officially, and expect at minimum to lose your job if they have any way to connect you to exposure (or even strongly suspect it).
Re:Can anyone elaborate on this LLVM v. RMS issue?
on
GCC 4.0 Preview
·
· Score: 1
Not a bad point. I've interacted with him a few times (by email Way Back When in ~1986) and in person a few times (back in the 80's).
Philosophically I have serious problems with his position - not that that's unusual. And yes, he does defend his positions well - but always remember that they're based on his social philosophy; he sees all of these issues as levers to use in getting to his social goals. And like most absolutists of any nature, the majority of people (including his supporters) might not like the results if he got his way in any major manner.
In this case, he's trying the Jedi Mind Trick: hoping people ignore what's in plain sight. LLVM may make it slightly easier for someone to write an external utility to crunch on IR data - but only a bit. As was pointed out, they can do it today and just release the changes to GCC that make the IR code visible. Poof.
Homeplug-style in-home-networking doesn't tend to cause the sort of interference you're talking about (certainly not on AM). You're thinking about BPL (Broadband over Power Line) technologies, that ham radio enthusiasts have been complaining about.
I would assume that they're planning security at least as good as HomePlug (which they're competing with), which uses AES encryption. RF isn't your issue; the reason security is required on HomePlug-type networking is that the signals are received (typically) by 2-5 other houses attached to the same transformer. (Some houses are the only house on their transformer, like mine.)
No, programmers should avoid comments for clearer code not because it takes 20 seconds to write them, but because it takes a lot more time to update commented/redundant code and it usually leads to inconsistent and incorrect documentation as the code evolves.
Comments are a form of redundancy to the code as well as testing, static typing, etc. Redundancy has its advantages but it is mostly disadvantageous as it makes changes difficult and in the case it is not automatically checked for consistency (documentation) it usually leads to the lack thereof.
Yes, comments are a form of redundancy, but this is generally a good thing. Yes, updating comments sometimes adds to the time to change the code - but that is not a bad thing. It can be a good thing if it forces you to think about how the change interacts with the code around it.
A lot of code can be written as to not require comments for proper understanding. The best documentation of what the code does is the code itself:
Its always up-to-date
Its always completely consistent with the behavior of the program
Its not ambiguous
Writing clear code is a good thing, and certainly clear code needs less comments than complex code - though the interactions between one bit of clear code and another can still need commenting.
The best commenting I've seen isn't (of course) the "I'm so tricky, watch this!" style, nor the assembler "add 1 to i" style. The best I've seen not only explained what was going on, it explained the reasoning behind choosing the algorithm(!), what others were tried and why they were rejected, and what possible edge conditions would exist if the environment the code was used in changed and how they could be handled if they ever became possible.
I've also worked with a great(*) programmer who as the first thing he did when looking at code was strip out every comment. All his variables names were 1 or two characters. He made frequent use of overflows and edge conditions as part of normal operation. His code was tight and very fast (this was image compression/decompression code). It was also close-to-impossible to maintain or debug (yes, I had to). You could read a page of it for hours before figuring out how in hell it produced the right results. For added amusement, when I gave him some modified code to look at, he came back and asked why there was an empty 'else' case. He's stripped the 4 lines of comments from the else that explained why it didn't have to be dealt with.
The eye is most sensitive to green, but the energy of the laser is the same, so any heating-related damage would be similar. The danger from lasers to the eye is generally that the energy is concentrated in a VERY small area (very few cells) and not just overloads them, they heat up and are damaged - or so I believe, IANAD (I Am Not An Doctor).
So while a green laser will look brighter (and may cause overloading and temporary blindness more easily), I believe any damage would be similar to a red laser.
And yes, be very wary of anything justified by 9/11, terrorism, etc. Even if everyone in the government is acting out of honest concern for the safety of Americans, etc, they can still go way too far in reacting to something like this, especially people who believe (as many fundamentalists like Ashcroft do) that the ends justify the means, and that they know what's good for people and aren't concerned about imposing those beliefs.
Someone can have no evil(*) intentions and still cause major harm to liberty (and cause what many would call evil).
Lots of discussion of the blind; not much of the hearing-impaired. While not computers per-se, something very useful for the hearing-impaired is a good videophone. Webcams can work, but webcam codecs (and older videophone codecs) don't get smooth motion at a low bitrate (low for videophone == cable/DSL upstream of 128-384K). Also the problem with webcams/ichat/msn meeting/etc is that it doesn't work like a phone - both have to happen to be at a computer (and know the other is via buddylists, etc) in order to make a call.
You want a smooth framerate more than anything (including resolution) for the hearing impaired (or so they tell us) to get good sign language recognition. Stuttering, dropped frames, low framerates (20 fps or less), and adaptive framerates all cause problems for sign language.
Disclaimer: I work for WorldGate. We designed and produce the Motorola Ojo, a 30 fps H.264 consumer videophone.
Sniffing won't even help if they really care to obscure things. The pattern of hits on a server; the actions a character takes in a MMORPG (doesn't have to be 'chat' in the engine - movements, other actions, etc); too many options to name. The one thing is that most of these require pre-coordination to set up a way of hiding messages in plain sight (a code in a way if you will). It doesn't have to be very elaborate, though, and there's effectively no way to stop people from communicating without being tapped if they really want to.
Slashdot Mirror
Not only do you need to translate strings (and as you say, use real live translators to do it, at least for anything you care about), but you also need to deal with formatting order (especially in printf-like statements).
l ocal_money_string(amount)).
In many languages, you have strings like this:
"You, %s, owe us %s dollars."
that are used with formatted print statements such as printf() that make assumptions based on ordering: printf(get_locale_string(you_owe_us_string),name,
In another language, the ordering of name and amount may NOT be the same. You really need to use an indexed string inserter like this:
"You, %1, owe us %2 dollars." This way a localized string could have %2 first, then %1.
In Scala (http://www.scala.com/) we handled it this way. Very effective (so far as it goes).
Another important thing: French is not just French, English is not just English. There's US English and British English; French-Canadian and French, etc. And that's ignoring things like date ordering, monetary issues, etc.
It's Brendan Eich, not "Brendad"
That doesn't solve the problem, which is this:
DNS and the web have made all names/trademarks "global" be default. You can't have 27 Acme Cleaners scattered across the nation all with acmecleaners.com/biz/etc. And as others have pointed out, the whole reason for the problem is that people search for the website of a known company by typing acmecleaners.com and hoping it resolves to the "right" acme cleaners; i.e. they use DNS as a search/indexing tool. I've been guilty of this myself, though I've mostly taken to using Google - far more likely to get the right domain by typing a company name (and sometimes a little other info) there.
This leads to lots of angst and lawsuits over domains (especially for more "generic" ones), consumer confusion, etc.
Solutions (ok, not really, but ways to minimize the problem):
1) Choose a relatively unique name when starting a business - and search for it, not just on the web but in yellow pages/infospace, etc. (Not an option for existing ones.)
2) Advertise and constantly reinforce the URL for your business.
3) Make sure if someone looks for you in google/yahoo/etc with a reasonable search string they can find you. Don't game the system (try to make all Acme Cleaners searches go to you), but make it useful for consumers (try to get Acme Cleaners Boston to go to you - reinforce that on your main page).
4) if you have a name "foobar", and foobar.com is take, find something else similar that's easy to remember. I work for Worldgate Communications. "worldgate.com" was taken before we started, so our domain is "wgate.com" - and it doesn't hurt that much.
5) Don't spend huge amounts of time and trouble trying to lock up every variant TLD. The extra traffic from those isn't huge, and is less if you do the things above.
It doesn't have to return in constant time, but it does have to return in time invariant (or very close to) on the key.
This class of attack isn't new. The AES selection people considered it but didn't think much about the cache line issue (or the sbox table lookup time issue and how it interacts with caches).
The class of attack of using CPU load/switch latency to pass information from a secure process to an insecure one dates back at least to the mid or early 80's (first time I read about it at RPI).
If you noticed, I was an AmigaOS designer... :-)
Note that some of these mechanisms don't require processes running; they involve time to respond to a request that requires cryptographic processing (encrypt/decrypt). The AES paper shows this attack can work over a network (though at severely reduced leakage rates). This also implies that for the network leakage case, you don't have to go to the same levels of extremes before the leakage rate becomes on the order of the brute-force cracking time, and thus a wash. In addition, if it's only network attacks you're protecting against, you merely have to guarantee that the packet response time is approximately constant (or doesn't vary with the key data), so you can "hold" responses until (say) 100ms have elapsed while doing other processing.
This issue exists with AES implementations as well (search for AES SBOX cache timing on google). The AES vulnerability is, if anything, more worrying in a way. It can be made to be constant-time, but at a serious cost in performance.
Here's another option: since this vulnerability depends on using the L1/L2 cache states to ferret out information, remove that from consideration. When processing an RSA (etc) key, have the code temporarily lock out context switches, AND have it take a fixed period of time to compute the result (or portion of the result), followed by flushing the cache. No data is left in the cache to analyze. The execution time of the code is fixed, so no dat leaks there. You don't have to make the algorithm a constant-time calculation if you can pad it at the end to the maximum (or close enough to the theoretical maximum that there's no true information leakage in practice). This helps avoid the potentially very slow algorithms that are truely constant-time. And flushing the cache at the end of each (portion of the) calculation removes that as a leak. (You need to flush it before waiting for the allocated time to elapse, note, and include max flush time in your calculation, and if possible factor into your calculation possible interrupt effects.)
A pain? yes. Requires extensive mods to crypto algorithm implementation? Yes (though perhaps not to the core calculation.) Requires OS support? Almost certainly. Requires HW support? Would be helpful but probably not required. Loss of performance? Yes, though far lower than disabling HT I imagine in normal cases (when not decrypting/encrypting).
Also, some of the restrictions above can probably be eased if the crypto algorithm is carefully designed and matched to the hardware.
Disclaimer: I am NOT a crypto geek! I have worked in processor and cache design, though.
I would assume their apps are dynamically linked against LGPL libs (if their apps directly use LGPL libs at all).
Realize their "warning" that it won't work may not be true in practice. (Though it violating your warrantee probably is true.) If you modify a lib and it accidentally deletes all your saved programs, it's not their problem.
More to the point, I suspect the anti-service-theft code makes it effectively impossible to replace a library - there's probably a disk and/or memory checksum that considers any change that isn't signed with their private key to be an attempt to hack the unit and steal service. This checksum process probably is outside of the app that uses LGPL (for example, burned in ROM/flash within the processor or chipset). So you can modify the library or recompile linux, etc and replace it - but the unit will probably simply fail to even attempt to start. Or the code is encrypted on the disk with a key you don't have access to.
LGPL has limits - which is part of why Stallman didn't like it to begin with. GPL has limits too; many of these things I mentioned above apply to GPL code as well.
IANAL, etc. Yes, some of these things may (depending on your point of view) violate the spirit of the GPL/LGPL. But be careful trying to decide whether they've violated the legalities of a GPL/LGPL copyright; it's not so simple, especially with devices with firmware (flash, disk or otherwise). It does sound like they're following the legal requirements of the GPL/LGPL as needed. The anti-hacking code in the processor/flash/disk probably will make it impossible to modify the code in the actual unit (and have it receive service!) You may be able to replace the code on the unit and use the hardware. Getting it to then receive encrypted broadcasts and record/show them will probably not be possible.
Just my guess. I haven't even looked at what they released.
You're assuming it's a monolithic executable. I'm sure it's not. It's proprietary stuff running on top of (possibly modified and released) Linux, with some LGPL libs (released I'm sure with any mods) and some GPL executables that are part of Linux userspace.
Totally within the bounds of GPL.
No, MTS - Michigan Terminal System. Created at Michigan State I believe; ran there, Waterloo, RPI, and 8 or 10 other universities (maybe more). Used to run 100-175 users on a 370/3033 and later a 370/3091(?) 4-CPU system. At RPI, the main computing center (VCC, Voorhees Computing Center) was (and is) an old chapel, with 20' stained glass over the terminals.
VERY different than MVS.
Probably the only OS that came with a full PDP-8 simulator as a system command - and the PDP-8 simulator was used once to break the security of the OS. Really. A buffer-overrun attack.
Exactly - the author of this "test" made a bad assumption: fsync() (or rather the windows equivalent) means it's on the disk. Understandable, and once upon a time it was true in Unix. fsync() doesn't (that I know of) issue ATA sync commands, though.
I used to beta-test SCSI drives, and write SCSI and IDE drivers (for the Amiga). Write-caching is (except for very specific applications) mandatory for speed reasons.
If you want some performance and total write-safety, tagged queuing (SCSI or ATA) could provide that (with write caching turned off). You'll still give up some performance, since the a single-threaded write application/FS will wait for data to be on disk before continuing. If the FS/app writes (say) 3 chunks of data that fill a track, with write caching off and tagged queuing, it's probably a minimum of 3 rotations (probably more like 4.5 or more) to write the data. With write caching, it's minimum 1, more like average 1.5 rotations. With a LOT of pain, you could break the single-threadedness of this in some cases by not waiting for tagged write completions and reporting success, while marking the VM pages as copy-on-write or some equivalent so the app won't overwrite the data that you're still writing (or, you could only return success to the app/FS when the data has been sent to the drive, but before it reports success). This (in a way) moves the write cache into the disk driver and thus gives you control over it. Perf will still be lower than letting the drive do it, perhaps a lot lower in some cases.
If you want _real_ performance and safety, turn on write caching, and when you hit a "safety checkpoint", tell the drive to flush the write cache to disk. I don't currently believe that ATA or SCSI drives generally ignore that command - please provide links if you know differently. It's not a benchmarking advantage to subvert that unless the OS/app is using it - but maybe OS's are turning fsync()/etc into ATA/SCSI sync commands, and the drive makers are lieing.
On MTS (IBM mainframe OS used at universities in the 70's/80's and probably into the 90's) there was a bug where when process switching, the FP registers of the last process to run were stored in a world-readable page of memory. The RPI ACM used this to create an inter-process communication program -- actually a 'chat' program (MTS had no inter-process communication other than files at the time).
"Genius" is not synonymous with "Best"...
("Genius" tends to be used for people who can do things others can't, or can figure out things others are stumped by. In fact, it tends by definition to be linked to things that others will have trouble following even if they do try to document. I used the term very deliberately...)
Not to say that some of what you say isn't reasonable. However, in this code, I don't want to hide what we're doing with the bits of the structure - this is an external (wire) interface, so at this level of the code I want to be explicitly concerned with the handling of the specific bits defined in the protocol. And the event loop is at a higher level; this is part of the equivalent to IsCompleteMessageAvailable().
Not naming names...
Said "genius" programmer was in fact really really good at producing working, bug-free, very fast code, and doing complex projects others had totally failed at. But (as you mention) you wouldn't want anyone less skilled than he was working on it. And that person had better be an expert at deciphering undocumented code.
He was also the author of a very good book on x86 assembly optimization, which might explain something.
And yes, the x = x++; was a typo.
Please excuse the incorrent indenting above; "<ecode>" doesn't work exactly like 'pre'
And if you lose your palmpilot (or it breaks), you need to get new passwords for everything, unless the data syncs to your PC (which it probably does). Which then makes it safe unless someone can keylog your PC - but you're probably toast if they do that anyways. :-)
Here's the original Science paper, with lots of details:
Original Paper
Note that the samples were hydrated (and demineralized, etc). LOTS of data there.
They do have rights in this case - rights to what you wrote. If _they_ distribute the entire package including what you wrote, they have to comply with the license for the code you modified, which (if GPL) requires that they release the source including your mods. Effectively, they're the modifier of the package, not you.
If they don't distribute (use it internally, say), they do NOT have to make your mods public. And in many licenses, "public" means provide it to the people who buy the modified package.
They CAN patent things in the mods you wrote (some licenses may have something to say about distributing such code, and it wouldn't likely make it back into the source tree). They CANNOT patent things that were in the original code since neither you nor they invented them (duh).
This company CAN be sued by the rights holders of the original code. Their patent (if based on the code in the original project) will NOT be valid, but they can still file it and probably get granted. (If they knew it wasn't patentable or don't disclose the prior art, it can be overturned on that alone probably - if challenged.)
Sounds like a lawyer (or manager more likely) there knows employment law, but really doesn't know anything about copyright law and doesn't care.
Be very careful if you decide to "go public" officially, and expect at minimum to lose your job if they have any way to connect you to exposure (or even strongly suspect it).
Not a bad point. I've interacted with him a few times (by email Way Back When in ~1986) and in person a few times (back in the 80's).
Philosophically I have serious problems with his position - not that that's unusual. And yes, he does defend his positions well - but always remember that they're based on his social philosophy; he sees all of these issues as levers to use in getting to his social goals. And like most absolutists of any nature, the majority of people (including his supporters) might not like the results if he got his way in any major manner.
In this case, he's trying the Jedi Mind Trick: hoping people ignore what's in plain sight. LLVM may make it slightly easier for someone to write an external utility to crunch on IR data - but only a bit. As was pointed out, they can do it today and just release the changes to GCC that make the IR code visible. Poof.
Homeplug-style in-home-networking doesn't tend to cause the sort of interference you're talking about (certainly not on AM). You're thinking about BPL (Broadband over Power Line) technologies, that ham radio enthusiasts have been complaining about.
I would assume that they're planning security at least as good as HomePlug (which they're competing with), which uses AES encryption. RF isn't your issue; the reason security is required on HomePlug-type networking is that the signals are received (typically) by 2-5 other houses attached to the same transformer. (Some houses are the only house on their transformer, like mine.)
Comments are a form of redundancy to the code as well as testing, static typing, etc. Redundancy has its advantages but it is mostly disadvantageous as it makes changes difficult and in the case it is not automatically checked for consistency (documentation) it usually leads to the lack thereof.
Yes, comments are a form of redundancy, but this is generally a good thing. Yes, updating comments sometimes adds to the time to change the code - but that is not a bad thing. It can be a good thing if it forces you to think about how the change interacts with the code around it.
A lot of code can be written as to not require comments for proper understanding. The best documentation of what the code does is the code itself:
Writing clear code is a good thing, and certainly clear code needs less comments than complex code - though the interactions between one bit of clear code and another can still need commenting.
The best commenting I've seen isn't (of course) the "I'm so tricky, watch this!" style, nor the assembler "add 1 to i" style. The best I've seen not only explained what was going on, it explained the reasoning behind choosing the algorithm(!), what others were tried and why they were rejected, and what possible edge conditions would exist if the environment the code was used in changed and how they could be handled if they ever became possible.
I've also worked with a great(*) programmer who as the first thing he did when looking at code was strip out every comment. All his variables names were 1 or two characters. He made frequent use of overflows and edge conditions as part of normal operation. His code was tight and very fast (this was image compression/decompression code). It was also close-to-impossible to maintain or debug (yes, I had to). You could read a page of it for hours before figuring out how in hell it produced the right results. For added amusement, when I gave him some modified code to look at, he came back and asked why there was an empty 'else' case. He's stripped the 4 lines of comments from the else that explained why it didn't have to be dealt with.
The eye is most sensitive to green, but the energy of the laser is the same, so any heating-related damage would be similar. The danger from lasers to the eye is generally that the energy is concentrated in a VERY small area (very few cells) and not just overloads them, they heat up and are damaged - or so I believe, IANAD (I Am Not An Doctor).
So while a green laser will look brighter (and may cause overloading and temporary blindness more easily), I believe any damage would be similar to a red laser.
And yes, be very wary of anything justified by 9/11, terrorism, etc. Even if everyone in the government is acting out of honest concern for the safety of Americans, etc, they can still go way too far in reacting to something like this, especially people who believe (as many fundamentalists like Ashcroft do) that the ends justify the means, and that they know what's good for people and aren't concerned about imposing those beliefs.
Someone can have no evil(*) intentions and still cause major harm to liberty (and cause what many would call evil).
You want a smooth framerate more than anything (including resolution) for the hearing impaired (or so they tell us) to get good sign language recognition. Stuttering, dropped frames, low framerates (20 fps or less), and adaptive framerates all cause problems for sign language.
Disclaimer: I work for WorldGate. We designed and produce the Motorola Ojo, a 30 fps H.264 consumer videophone.
Sniffing won't even help if they really care to obscure things. The pattern of hits on a server; the actions a character takes in a MMORPG (doesn't have to be 'chat' in the engine - movements, other actions, etc); too many options to name. The one thing is that most of these require pre-coordination to set up a way of hiding messages in plain sight (a code in a way if you will). It doesn't have to be very elaborate, though, and there's effectively no way to stop people from communicating without being tapped if they really want to.