Fair enough, I obviously didn't do my homework on the TRON half of TRON-Linux, and assumed it was a newer project.
Thanks to all who provided answers and insight.
Trademark infringement w/ Mentor's Nucleus RTOS?
on
TRON + Linux = "T-Linux"
·
· Score: 3, Interesting
As much as I despise frivolous trademark infringement suits, this one seems to be strongly in favor the side of the trademark holder, were it to become an issue.
Mentor, the makers of the real time operating system "Nucleus" (tm), would appear to have reasonable grounds for confusion with a product in the same market place "The Real Time Operating system Nucleus Linux" aka TRON-Linux.
Sure you can argue Nucleus is a general term, but I doubt that argument holds much weight when both names are used in the same market. Heck, these two are even in the same tiny corner of the computer word (realtime operating systems).
Of course, IANAL, much less a trademark specialist. Anyone more educated on the topic care to comment?
The fundamental point here is not destroyed vs corrupted, it's bootloader vs partition.
The partition table won't be mangled and your partitions themselves will be fine, but grub, your bootloader, may be stepped on and need to be re-installed if you want to try to boot the system.
The SpamAssassin Developers have already opened a bug to discuss this issue, but the "heavy scoring" contributors to it being spam-tagged would appear to be Razor and DCC.
Of course, it's always struck me odd that anyone would use DCC on any system they didn't want FP's on. DCC is a "bulk" email tracker, not a "spam" email tracker (ie: any mass-mailing should be in it, solicited or not).
At any rate, if you want to monitor the SpamAssassin bug regarding the Crypto-gram newsletter, you can read it here:
I don't think I'm a god, I think you're underestimating what people can do. I also think you're failing to realize I'm not talking about a common occurrence, but an absolute peak of endurance.
Your argument against the original poster is that this level of thruput is impossible. I take that to mean impossible even under the most extreme cases of human endurance and moments of brilliance. To that assertion, I say bullocks.
Would you ever want to run a project that way? Hell no! Have people done this before, hell yes. Have I done this before, hell yes. Am I a god for it, heck no! But if you see working more than 16 hours a day as impossible, you're weak.
- " it's either the beginning of the end.." or what? You failed to complete that thought. In any event, I correlated this to the dotcom startups. Clearly a that's a great example of the beginning of the end. I didn't say it wasn't the begining of the end, just that it can be, and has been, done. I'm also not saying heroic coding is recommended behavior.
- Yes, I'm assuming a massive-crash scenario at the end of the week, and I'm assuming sleep deprivation to the point of immune system compromise during the week. Again, I'm not talking about something people do every month. I'm talking about a coder's absolute maximum endurance.
- I'd never make a project depend on this kind of thruput. I'm merely stating that it is possible to happen a a few "peak" points of hard work in your lifetime.
If the absolute lifetime peak of your exertion, ever, is to put in 16 hours a day for a week, you *are* pathetic.
Sustaining 16hours a day, with 6 hours of sleep a day is what you consider hardcore coding? Wow, I didn't realize I was in the uber-endurance category of coders. I know the average coder is a fat, lazy, idiot, but 16 hour days? Man, you're weak... And I'm not just talking about insane college students. I know people >40 years old that can push harder than 16 hours a day for a week when needed.
Now let's realize this is a "put 100% into it" for a short period of time scenario. One week. I'm not talking crunch time at some large lazy company. I'm talking sleep on the floor of your office, have people bringing food to your desk and collapse at the end of the week type coding. You know, insane dotcom startup type stuff.
Based on that, I'm assuming a more reasonable level of 20 hours of hacking a day (I *have* done this) that's 3.75 lines of code per hour or one per 16 seconds. Now, I don't consider that a particularly insane level of coding for a single-week burst of hard-core coding following a week of hard-core thinking.
I do agree that I don't see how anyone could maintain that kind of speed for months. It's more what happens when you've been thinking over some really monstrous code for a while, finally get how it is going to go together down in your head, and sit down to implement it and have zero time to write it in.
I dono, maybe me and my co-workers are some kind of gods, but I don't see these "one week" numbers as outrageous.
Ok, this is a bit on the OT side, but has anyone wondered why they decided to name this product Tungsten?
I'm guessing they wanted to call it Titanium but realized that was already used by Handspring. So they settled on the similar sounding Tungsten.
However do they realize that Tungsten is the 6th densest element there is? Sure, Platinum is a bit denser, but at least it's a rare/precious metal and has a fairly high value. Tungsten is generally used because it's fairly reasonable in priced for being as dense as it is (it's substantially more dense than lead) or for lightbulb filaments.
A block of tungsten (admittedly solid) the size of a palm i750 would weigh over 6lbs. Using common 90% alloys which are more machinable it would be 5.4 lbs (alloy specs from http://www.tungstenprod.com/Alloys/SD170.htm)
Generaly when I'm looking for a palm I'm thinking "light" "compact" "hi-tech" "stable" etc.. not "dense" "heavy" or "good for making armor piercing bullets out of".
What next, a lighter, more flexible version called the Palm Lead Pb?
First off, a point I agree with you on: >It boils down to - do you really need to have the >data 100% secure. If you don't, then of course >don't do it. But if you even think you might do, >then surely it makes sense to have the ability to >do it in place, so you can use it if you need to.
Agreed. If you really need it, nothing else will do. However, encryption is only one tiny piece of security, you'd better be sure the rest of your setup is up-to-snuff:
> I`m not sure why you think OTPs are so a) expensive and b) clumsy to use. >The actual program to do the en/decryption can be written in VB in a few minutes - it's trivial
a) because it is clumsy and b) because it is expensive. This has been proven, Governments have and do use OTP's. There is a genuine reason why OTPs are rarely used in even government/military applications anymore.. it was too clumsy and too costly FOR THEM to use in realistic scenarios. Really, People aren't just discounting it without trying it.
I'll give you the application can be trivialy written in any language, heck, you can do it by hand easily enough. But the cost of actual use of OTP's is high when you realize how much surounding security is needed:
1) secure random number generation:
hardware: ~$700, consisiting of a dedicated PC w/CD burner a camera and a few lavalamps.
software cost: free
facilities: if you want this cipher to be more costly to break than analyzing a block cipher, you'd better be damn sure that breaking in here is a multi-million dollar adventure. If someone can pick a lock, break in and copy your pads, you're lost.
Dedicated room, Monitored alarm system, tamper-seals on system, high-grade locks, extra heavy walls.
~8,000 + alarm service fees.
2) OTP software: free
3) Trusted personal exchange of OTP CD's (again, you have to be sure nobody can copy these, so it must be hand escorted).
Travel expenses: ~$10 - $1000, depending on where your associate is and how far you have to go.
Salary for 2 days: (I'm thinking corporate, or your cost of missing work for a few days) $160 - $1600, depending on payrate of person traveling. (note: this only applies if the travel isn't across town and involves flying somewhere far)
This can probably be restricted to once annually
4) Burglary Rated safe ( TL-15 or better, preferably TLTR-30 or better) to store the pads in:
~$1000 (assuming TL-15) per site, per safe.
(note: the fire safes you can buy at target are NOT designed to resist burglary attempts).
Again, if someone can break in, grab and copy your pad, it's not secure. If you aren't worried about breakins, why are you worried about unbreakable encryption?:)
So once you start including physical security to obtain a minimal level of safety against having your pad stolen, yes.. it is damn clumsy and quite expensive.
>Simple free products like OpenBSD with pf/nat do.
In the context I meant it, I'd certianly not call OpenBSD a "simple product". By simple I meant "designed with minimal work".
OpenBSD has got a lot of well thought out and well placed security design. In that respect, I'd call it one of the higher end, carefuly engineered products.. even if it is free:)
Agreed, it's not impossible to use a OTP, and there are situations where it isn't much hassle. The case you describe is certainly realistic, however it is not very common and the benefit of OTP for this situation is unclear.
Generaly the most valuable data transferred is transmitted in circumstances where OTPs aren't practical. Sure it's easy to use for your buddy across town, but what about the corporate office halfway across the world that needs a product design worth 100's of millions of dollars of the open market. Or what about the corporate VPN which transfers 100's of megs a day?
And yes, OTP is possible even in these situations, but the practicalities are so difficult and costly that it's rarely, if ever used.
Let's face it, I've never had any personal information in my possession worth more than a house. Sure, some information is personal finances, and some of it might be embarrassing, but embarrassing me, or embezzling a few grand from my credit card account doesn't get anyone anything worth the effort of analyzing a decent (2^80 or longer) block cipher. Heck, I'd question if anything personal to me was worth breaking a 2^56 cipher like DES, and that doesn't take very long, but I'm not taking that chance in general.
Any block cipher can be brute-force broken given enough time and enough money. They question you have to ask is the information protected valuable enough to be worth spending the time and money on? Does someone really want to dedicate a several million dollar machine for several years to break a 2^64 strength-cipher you used? That information would still have to be worth a decent portion of the cost of the machine after a few years of crunching.
In reality the most practical uses of OTP's are the situations where the added security of a OTP is more-or-less moot. If I'm in close physical proximity with frequent meetings, and it's only to a friend, the value of the data is low, and the odds that I'm going to have anything to say that I can't say next time I see them is also low.
It's larger organizations like banks, companies, and governments that are exchanging large volumes of information that make the fattest, juiciest targets for analysis and they can't deploy OTP's for all of their needs, there's just too much data to do so.
The fundamental problem with practical use of one time pads is that you need a separate secure mechanism by which to agree upon the pad. And of course, to be absolutely secure that pad needs to be:
1) truly random
2) only used one time
3) as long as the data to be encrypted.
Those three are the assumptions about the pad required to reach absolute security that make OTP's impractical. If all three are not met, or the exchange is not secure, the security of the OTP is no longer absolute.
Most generation mechanisms that are truly random only generate the pad at one location. That will result in you needing to courier the pads to the party that will eventually receive your messages. If you can already securely courier the data of the pads, in most cases it makes sense to just courier the data itself.
Some alleged one-time pad systems that are practical use a password or short random secret fed into a PRNG to expand the key to the length needed as a pad. However the output of a PRNG is not truly random, and thus the security of the "unbreakable" one-time pad is reduced to the strength of the PRNG against prediction. Most PRNGs are weaker than brute-force analysis of a 2^128 key block cipher. Many PRNG's are actualy highly linear and very predictable (see some of the research on TCP sequence number prediction to see just how hard it is to get a PRNG that isn't trivially predictable.) There is EXTENSIVE cryptographic research pointing out how foolhardy it is to think that a PRNG extended key is as secure as a OTP, and thus unbreakable.
Another practical problem for OTPs is the storage of the pad itself. The pad is quite lengthy, at least as large as all the secure data you want to transmit before exchanging pads again, and needs to be stored in a secure fashion at both the sender and recipient's facilities.
One of the primary reasons for the creation of block ciphers and other symmetric encryption mechanisms is that they reduce the amount of data that you need to securely exchange into a relatively small key. That small key can then be used in the transfer of a significantly larger portion of data, and it is now possible the algorithm is weak, but at least the small keys make these ciphers by far more practical to use in real-world situations than a OTP.
Agreed, such devices tend to have poor ISNs, but then again, they are for home use, and the ports they serve only respond on the INSIDE. Outbound traffic passes thru with more-or-less the same ISN it started with.
Unless you don't trust people on your home lan, it's not much of an issue. Yes, it should be done right, but the only people that can exploit this are those within your network. If they are in your home, they can do much worse than hijack your session as you configure the router.
As for outbound traffic, if you connect to an outside website from an inside PC, it uses the ISN that the PC generated and doesn't change it or adds some simple fixed constant. It still retains all of the entropy of the original PC's ISN. Nobody from the outside should be able to connect to the configuration server in the "DSL router" device. Hence, nobody from the outside really sees the poor entropy of the DSLRouter's ISNs.
Only higher-end firewall products, ie: the cisco PIX, attempt to mangle the ISN generation as they translate hosts. Most of the simple products do not, and certianly none of the $100 DSL routers do.
Also good ISN generation is actualy important to more "commercial" grade routers, since these devices are sometimes deployed and administered remotely, generate tunnels, etc. Thus these routers/firewalls sometimes have exposed ports, or exposed client traffic on a public network as they are being reconfigured.
Of course, many are only configured localy, or over a local LAN, which makes the risk a lot lower, but also users on corprate lans are generaly less trusted than those in your own home.
By the phrase "You are responsible for maintaining the confidentiality of your password and account information." I don't believe Microsoft is requiring you to maintain confidentiality, but instead they are disclaiming any of their own responsibility if your password is disclosed. ie: if you give your password to someone else, don't blame us, we're not responsible.
Of course, other clauses probably give them the rights to shut down accounts which they realize have been comprimised. For security reasons, of course, MS clearly only wants to protect their users:)
It's also a bit amusing and twisted to realize that statement also means that if Microsoft is hacked and your password and account information are stolen, that's your problem, not Microsoft's. Clearly you should have been responsible enough to not give it to MS in the first place:) Or maybe you should have been responsible enough to fix their security problems yourself before your account information got disclosed:)
Why not have a small IR beam sensor (you can buy the parts at most ratshacks) and have that set off a buzzer/siren. Position the beam sensor pair within range of motion of her hand so all she needs to to is interrupt the beam with her fingertip.
Ratshack even used to sell a larger-scale version of this as a door entry bell. You placed the unit and a reflector on either side of a doorway and anytime someone walks through the beam a chime sounds. Most ratshacks had these set up and operating to alert the salespeople to incoming customers during off-hours.
You might be able to find a pre-made version of this device on a small scale for detecting cabinet openings, or as a small portable "hotel room alarm" but most of these kinds of devices will not use this mode of sensing. (most cabinet alarms sense the light pouring in from the room into the cabinet, and most hotel alarms hang on the doorknob and sense being rocked around with a mercury switch.)
I wouldn't say it secures *nothing*. In fact, I'd say it secures a lot of things many people don't even think about. But you are right, it's not as strong in the "prevent the buffer overflows" category, and most of the things it does a good admin would do by hand anyway.
It's got some pretty good file permission changes that work very well for server environments. And yes, file permissions really do matter. Even on the simplest level it will ask you to remove SUID permissions from ping, dump, traceroute, at, etc. I know for sure there's been at least one local user -> root user exploit for dump that would be foiled if it were non-suid. There was even one this year for at which allowed the same privilege elevation on RedHat versions prior to 7.2:
http://rhn.redhat.com/errata/RHSA-2002-015.html
Of course, a good admin should go through and audit which files are SUID him or herself and kill off ones which aren't used by non-root users. But this makes it a bit easier.
And yes, removing the SUID bits does make fewer commands available to non-root users, but let's face it, do non-root users really need to be able to run traceroutes and backups from your webserver?
The only major objection I have is that Ars is presenting some WEP problems as being RC4 problems ie: that RC4 is broken and cannot be secure if implemented properly. "The main problem with WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure." I'd change that to read ".. has been proven insecure if research notes regarding these problems are ignored."
They claim the RC4 algorithm itself is broken, which it is to some degree, but there's lots of information on how to avoid these problems that was available prior to the design of WEP. I also dislike their implication that RC4 inherently uses a 24 bit IV, that was an IEEE decision, RC4 can use an IV that's as large as you want.
RC4 is reasonably secure when implemented correctly, but IEEE ignored the very well known and clearly stated fact that when using RC4, keys must not be re-used for the same data. And that's not surprising, block ciphers are greatly weakened by such things too, which is why anyone in their right mind uses a decent sized IV. RC4 is weaker to key reuse than block ciphers because of its design, but that was a well known fact prior to the design of WEP.
Weak keys are a genuine weakness in RC4. However, they too are well documented and can be easily detected and skipped prior to use. The fact that WEP uses a 24bit IV makes it particularly easy to create a table of IVs that weak, making this problem significantly worse. A great paper on RC4's weak keys, and how to avoid the problem, was posted to sci.crypt in 1995:
http://marcel.wanda.ch/Archive/WeakKeys.txt
So all the weaknesses in WEP that stem from the use of RC4 as an encryption algorithm were well documented, and methods of avoiding them resulting in weaknesses were well known, but the IEEE chose not to heed them. They were trying to make something "secure enough" and traded off things like using a short IV without consulting the cryptographic community about the implications.
Hindsight is 20-20, but I can't exactly call these RC4 flaws. I mean, if you had a power tool and you ignored the warnings printed in the manual, would you blame the tool when it fails?
Using a short IV is clearly an implementation flaw, the fault of WEP not RC4. IEEE wanted to save a few bytes of overhead and purposefuly chose a short IV. The weak keys are a flaw in RC4, but just generating a few bytes and discarding prior to using the key helps reduce the scope of this attack dramaticly. Even better is to detect and avoid the use of the weak keys in the first place, or do both. Since this was widely known when WEP was designed, I consider it to be a implementation flaw in WEP as well, albeit one that stems from a weakness in RC4.
Yes, but in this country there is a concept referred to as negligence. I am not a lawyer, but if my understanding of the law is correct if you are knowingly negligent in securing a resource which is known to be able to cause harm (monetarily or otherwise) when stolen, you are in some manner liable for the damages caused. Correct me if I am wrong, but if I ran a gun store and refused to lock the door when i left at night, despite being warned that kids were walking in and stealing the guns, I would be guiltily of manslaughter (at least) if one of those guns was used in a murder. Given that I premeditatedly chose to keep the store unlocked despite being advised of the risks, it might even be 1st degree murder (I'm not sure, IANAL as I already said).
I am not an "expert" in the field of mailserver security either, but it is my opinion that this is a cut-and-dry case of negligence on Johns part, and I am disgusted that he would go so far as to try to abuse the first amendment in this manner.
This security problem is so well known, and so well documented there's even an RFC on the matter, RFC 2505. And while this RFC is a description of current best practices, not a protocol requirements document, the list of recommendations under section 2 specifically states:
1) MUST be able to restrict unauthorized use as Mail Relay.
Don't believe me, go here: http://www.ietf.org/rfc/rfc2505.txt
This implies to me that despite the existence of technical methods to solve this problem (SMTP authentication for one), and having been advised of the impact this is having on others, John Gilmore is bent on ignoring industry standard practices for properly securing a mailserver. Even Yahoo can figure out how to configure their SMTP server to use authentication, and the eudora mail client that Gilmore specifically mentions on his page is capable of using SMTP auth (I know, I use eudora and have a yahoo account).
So how exactly is this a matter of free speech and not an attempt to contain the damage caused by a negligently configured mailserver operated by an administrator who is not ignorant to the industry standard methods of preventing the problem, and appears to be merely ignoring such standards for the sake of convenience? Sounds a lot like a "well, locking my store is a hassle because I have to remember to bring my keys with me when I go to work so I leave my gun store unlocked" argument. (admittedly the damage caused by this is much lower than a gun store, but it is fundamentally the same argument he's making)
On his page Gilmore also makes the argument that the filter Verio has placed upon his internet connection is sufficient to stop the damage, this gives them no grounds to terminate him. What I believe that Gilmore is failing to realize is that he is placing the responsibility for correcting his own security problems on Verio. Now, due to the negligence of one of their customers, Vero has to maintain a filter to ensure that customer does no damage, and you could even make the argument that if the filter fails, now *they* are negligent and liable for the damage caused. If I ran and ISP I certainly would not want that liability.
Now Verio is considering not disconnecting him because he's agreed to do some form of rate limiting? Sorry, this is not the proper solution to this simple problem.. it merely reduces the rate of damage caused to a less problematic level.
(yeah, I'll secure the gun cases so you can only take one gun out every five minutes, which will prevent someone from coming in and taking more than one gun at a time, because I still don't want to put a lock on my door, even though the lock is free and I can install it myself.)
I'm sorry Gilmore, you've been around the internet block several times more than I have, but I don't see how your arguments of free speech hold water. I'm also quite concerned that your actions are weakening the strength of the name of the EFF by associating them with a free speech argument which seems to consist of little more than baseless litigation. I expect legal cases with common-sense holes the size of Texas in them from the legal department of Amazon (patenting affiliation sales?) but I do not expect the name of the EFF to be associated with such frivolous matters.
Censorship? Bah! Get off dead center and secure your systems properly.
This new law is not about email opt-ins, under the new law companies can still spam VT residents into oblivion without opt-in. I feel your pain on spam, but that's got nothing to do with this law, and it makes your post offtopic (by accident).
The law prohibits financial companies from sharing information they have about you with other companies without your consent.
It does not stop them from sending you email, junkmail, and telemarketing calls themselves. It does stop them from sharing the contact info they with their "trusted business partners" (read: anyone willing to pay money for an address list) unless they have your permission.
So as best I can tell, the biggest impact is if you live in VT, your bank (or other financial service provider) can't sell lists of addresses of people with "accounts in good standing" to credit card companies. This removes a profit center from the bank, causing them to up service fees to compensate, but also removes unwanted credit card offers from your mailbox and phone service.
Well, I tend not to put much credit into the "physical stuff" of a bank. If a bank goes under the value of their "physical stuff" will likely be very insignificant compared to the potential debt of the company. Remember the S&L scandals of the 80's? Personally I find the fact that a bank is federally insured much more reassuring than their "physical stuff". (Paypal is not a bank and not insured as one) Even FDIC has its limits, but it provides far more backing than the paltry physical assets of most banks.
think about the assets of a small-mid sided bank office (wild guesses here, I'm not a banker):
Commercial building maybe 500k, but is likely leased
Computer equipment: 200k
office furniture, pens, etc: 100k
specialized facilities (safe deposit vault): 500k
So their physical assets might be as much as 1.2 million, supporting moderate number of small business accounts (200 maybe) and a decent number of personal accounts (3000 maybe), again, more guesses. Assuming an average value of these accounts at $2000 each (guessing) that's 6.4 million. And that's just the deposit side of things, not the loan side. Even with the wild inaccuracies of my guesses, it's not hard to see that the physical assets are not likely to match up much against the value of the accounts.
Well, I don't know about chip, but when I file an abuse complaint, I tend to include the entire spam message so that they can verify the content as a commercial email. They don't have to read the whole thing if they don't want.
These days with MS outlook html spam mails, 50k is a bit large, but not unheard of. Admittedly my largest spam for today is 18k, but I've gotten some whoppers before. (On the 26th I got a 42k byte spam.)
If @homes AUP department can't handle a single 50k email, they've got problems;)
If you just want to know what certian attacks look like, I might suggest going to snort.org and looking at the Intrusion detection rules they have. (downloads, snort-rules-current)
While this isn't a pretty-pictures way of doing it, they do contain a lot of signatures for suspicious packets. Be ready for information in this kind of format:
Which means a tcp segment from an outside machine on port 80, to an inside machine on port 21554 with the text content "Girl" might be an attempt to access the "Girlfriend" trojan horse.
Better yet, why not install and run snort on a low-end box and let it identify the wacky ones for you. I run one on a console only OpenBSD box with a p-90 and it monitors a T1 just fine. Another runs on a 486-120 under console-only linux.
There is even a Window$ version for those that prefer that platform.
I once had a cheap espresso maker shipped to me via UPS a couple of years ago (95-96). Admittedly the unit was shipped in it's store-shelf box, which is under UPS specs for box strength. (UPS used this as an out to avoid damage liability)
The damage done to the espresso maker was so severe I still cannot fully explain it to this day. The Espresso maker consisted of a rather sturdy rigid plastic housing and a very thick metal pressure jar inside. The base of this unit could clearly support in excess of 150lbs static weight without damage to the plastic housing.
Upon arrival the box height was reduced 4", the plastic housing of the unit was significantly crushed inside and the plastic control knob was sheered off. Strangely the glass decanter was unscathed.
Given the light weight of the device, a drop from a warehouse height ceiling (20-30') onto concrete would not have been sufficient to cause this level of damage to the device. My best guess is a heavy (>100lb) package was dropped onto this box from a moderate (3-4') height. ie: someone strong threw a very heavy object into a truck or onto a pile of boxes, crushing everything in its path.
Since this experience my rule-of-thumb for UPS shipping expectations are:
1) expect your package to have to withstand being thrown 15' into a hard object if it is light, 5' if it is >100lbs
2) expect it to have to withstand someone dropping a large heavy package onto it.
The bottom line is to expect that some UPS handlers really don't seem to care, they just throw stuff into piles and onto belts. Armor your packages accordingly. I at minimum use double-layer heavy gauge cardboard, even on light items. (sometimes I kludge this by cutting panels and lining the inside of the box with them and gluing them in place. As long as they are an exact fit you still gain crush resistance.) Heavy items may be wooden or plastic frame reinforcing the inside of a cardboard box, or stronger construction.
I had similar troubles trying to compile OpenSSH on my linux box. Then I discovered they have a separate "portable" distribution for non OpenBSD boxes. I picked the portable one,./cofigure; make; make install, done.
The "standard" tarball linked under "getting source" on the OpenSSH page is for OpenBSD and does not have a configure script, just a installer.
If you download OpenSSH for a non OpenBSD box, make sure you pick the portable version. (under operating systems click on your operating system, or go to: http://www.openssh.com/portable.html).
I agree, it's quite ridiculous that this post has been moderated up. It's purely off-topic.
I've actually USED paradigm C++, along with paradigm link and locate tools. It's for embedded application development. (ie: raw rom hanging off an x86 processor bus with no bios (you actually run where a BIOS would be), no OS, etc). The dev tools themselves run on ms-windows.
This tool has little to do with multithreading, in fact I don't belive it contains a thread library at all. (I could be wrong, but I never saw one and it's not a listed feature) It supports real mode, and if you're x86 can do it, protected. It will target as low as 80186's and NEC v## processors.
It also has nothing to do with UNIX. It's for people building non-pc x86 based systems that have no BIOS and no OS. It's for bare-metal embedded c++. You can't even run the IDE on UNIX, much less the target.
They have a site at devtools.com, visit if you're bored, see how much Multithreaded Unix support they have...
My personal opinions of this software aren't very high, but mostly because my opinion of x86 for raw-soldered embedded is pretty low. The product itself is relatively well written.
Slashdot Mirror
Fair enough, I obviously didn't do my homework on the TRON half of TRON-Linux, and assumed it was a newer project.
Thanks to all who provided answers and insight.
Mentor, the makers of the real time operating system "Nucleus" (tm), would appear to have reasonable grounds for confusion with a product in the same market place "The Real Time Operating system Nucleus Linux" aka TRON-Linux.
http://www.mentor.com/nucleus/
Sure you can argue Nucleus is a general term, but I doubt that argument holds much weight when both names are used in the same market. Heck, these two are even in the same tiny corner of the computer word (realtime operating systems).
Of course, IANAL, much less a trademark specialist. Anyone more educated on the topic care to comment?
The fundamental point here is not destroyed vs corrupted, it's bootloader vs partition.
The partition table won't be mangled and your partitions themselves will be fine, but grub, your bootloader, may be stepped on and need to be re-installed if you want to try to boot the system.
The SpamAssassin Developers have already opened a bug to discuss this issue, but the "heavy scoring" contributors to it being spam-tagged would appear to be Razor and DCC.
i ?id=1490
Of course, it's always struck me odd that anyone would use DCC on any system they didn't want FP's on. DCC is a "bulk" email tracker, not a "spam" email tracker (ie: any mass-mailing should be in it, solicited or not).
At any rate, if you want to monitor the SpamAssassin bug regarding the Crypto-gram newsletter, you can read it here:
http://www.hughes-family.org/bugzilla/show_bug.cg
Hehhehe, I guess that's what happens when I post quickly on slashdot while eating breakfast..
You are correct, that's 3.75 lines of code per minute, not hour.
Doh!
I don't think I'm a god, I think you're underestimating what people can do. I also think you're failing to realize I'm not talking about a common occurrence, but an absolute peak of endurance.
Your argument against the original poster is that this level of thruput is impossible. I take that to mean impossible even under the most extreme cases of human endurance and moments of brilliance. To that assertion, I say bullocks.
Would you ever want to run a project that way? Hell no! Have people done this before, hell yes. Have I done this before, hell yes. Am I a god for it, heck no! But if you see working more than 16 hours a day as impossible, you're weak.
- " it's either the beginning of the end.." or what? You failed to complete that thought. In any event, I correlated this to the dotcom startups. Clearly a that's a great example of the beginning of the end. I didn't say it wasn't the begining of the end, just that it can be, and has been, done. I'm also not saying heroic coding is recommended behavior.
- Yes, I'm assuming a massive-crash scenario at the end of the week, and I'm assuming sleep deprivation to the point of immune system compromise during the week. Again, I'm not talking about something people do every month. I'm talking about a coder's absolute maximum endurance.
- I'd never make a project depend on this kind of thruput. I'm merely stating that it is possible to happen a a few "peak" points of hard work in your lifetime.
If the absolute lifetime peak of your exertion, ever, is to put in 16 hours a day for a week, you *are* pathetic.
Sustaining 16hours a day, with 6 hours of sleep a day is what you consider hardcore coding? Wow, I didn't realize I was in the uber-endurance category of coders. I know the average coder is a fat, lazy, idiot, but 16 hour days? Man, you're weak... And I'm not just talking about insane college students. I know people >40 years old that can push harder than 16 hours a day for a week when needed.
Now let's realize this is a "put 100% into it" for a short period of time scenario. One week. I'm not talking crunch time at some large lazy company. I'm talking sleep on the floor of your office, have people bringing food to your desk and collapse at the end of the week type coding. You know, insane dotcom startup type stuff.
Based on that, I'm assuming a more reasonable level of 20 hours of hacking a day (I *have* done this) that's 3.75 lines of code per hour or one per 16 seconds. Now, I don't consider that a particularly insane level of coding for a single-week burst of hard-core coding following a week of hard-core thinking.
I do agree that I don't see how anyone could maintain that kind of speed for months. It's more what happens when you've been thinking over some really monstrous code for a while, finally get how it is going to go together down in your head, and sit down to implement it and have zero time to write it in.
I dono, maybe me and my co-workers are some kind of gods, but I don't see these "one week" numbers as outrageous.
Ok, this is a bit on the OT side, but has anyone wondered why they decided to name this product Tungsten?
I'm guessing they wanted to call it Titanium but realized that was already used by Handspring. So they settled on the similar sounding Tungsten.
However do they realize that Tungsten is the 6th densest element there is? Sure, Platinum is a bit denser, but at least it's a rare/precious metal and has a fairly high value. Tungsten is generally used because it's fairly reasonable in priced for being as dense as it is (it's substantially more dense than lead) or for lightbulb filaments.
A block of tungsten (admittedly solid) the size of a palm i750 would weigh over 6lbs. Using common 90% alloys which are more machinable it would be 5.4 lbs (alloy specs from http://www.tungstenprod.com/Alloys/SD170.htm)
Generaly when I'm looking for a palm I'm thinking "light" "compact" "hi-tech" "stable" etc.. not "dense" "heavy" or "good for making armor piercing bullets out of".
What next, a lighter, more flexible version called the Palm Lead Pb?
First off, a point I agree with you on:
:)
>It boils down to - do you really need to have the
>data 100% secure. If you don't, then of course
>don't do it. But if you even think you might do,
>then surely it makes sense to have the ability to
>do it in place, so you can use it if you need to.
Agreed. If you really need it, nothing else will do. However, encryption is only one tiny piece of security, you'd better be sure the rest of your setup is up-to-snuff:
> I`m not sure why you think OTPs are so a) expensive and b) clumsy to use.
>The actual program to do the en/decryption can be written in VB in a few minutes - it's trivial
a) because it is clumsy and b) because it is expensive. This has been proven, Governments have and do use OTP's. There is a genuine reason why OTPs are rarely used in even government/military applications anymore.. it was too clumsy and too costly FOR THEM to use in realistic scenarios. Really, People aren't just discounting it without trying it.
I'll give you the application can be trivialy written in any language, heck, you can do it by hand easily enough. But the cost of actual use of OTP's is high when you realize how much surounding security is needed:
1) secure random number generation:
hardware: ~$700, consisiting of a dedicated PC w/CD burner a camera and a few lavalamps.
software cost: free
facilities: if you want this cipher to be more costly to break than analyzing a block cipher, you'd better be damn sure that breaking in here is a multi-million dollar adventure. If someone can pick a lock, break in and copy your pads, you're lost.
Dedicated room, Monitored alarm system, tamper-seals on system, high-grade locks, extra heavy walls.
~8,000 + alarm service fees.
2) OTP software: free
3) Trusted personal exchange of OTP CD's (again, you have to be sure nobody can copy these, so it must be hand escorted).
Travel expenses: ~$10 - $1000, depending on where your associate is and how far you have to go.
Salary for 2 days: (I'm thinking corporate, or your cost of missing work for a few days) $160 - $1600, depending on payrate of person traveling. (note: this only applies if the travel isn't across town and involves flying somewhere far)
This can probably be restricted to once annually
4) Burglary Rated safe ( TL-15 or better, preferably TLTR-30 or better) to store the pads in:
~$1000 (assuming TL-15) per site, per safe.
(note: the fire safes you can buy at target are NOT designed to resist burglary attempts).
Again, if someone can break in, grab and copy your pad, it's not secure. If you aren't worried about breakins, why are you worried about unbreakable encryption?
So once you start including physical security to obtain a minimal level of safety against having your pad stolen, yes.. it is damn clumsy and quite expensive.
>Simple free products like OpenBSD with pf/nat do.
:)
In the context I meant it, I'd certianly not call OpenBSD a "simple product". By simple I meant "designed with minimal work".
OpenBSD has got a lot of well thought out and well placed security design. In that respect, I'd call it one of the higher end, carefuly engineered products.. even if it is free
Agreed, it's not impossible to use a OTP, and there are situations where it isn't much hassle. The case you describe is certainly realistic, however it is not very common and the benefit of OTP for this situation is unclear.
Generaly the most valuable data transferred is transmitted in circumstances where OTPs aren't practical. Sure it's easy to use for your buddy across town, but what about the corporate office halfway across the world that needs a product design worth 100's of millions of dollars of the open market. Or what about the corporate VPN which transfers 100's of megs a day?
And yes, OTP is possible even in these situations, but the practicalities are so difficult and costly that it's rarely, if ever used.
Let's face it, I've never had any personal information in my possession worth more than a house. Sure, some information is personal finances, and some of it might be embarrassing, but embarrassing me, or embezzling a few grand from my credit card account doesn't get anyone anything worth the effort of analyzing a decent (2^80 or longer) block cipher. Heck, I'd question if anything personal to me was worth breaking a 2^56 cipher like DES, and that doesn't take very long, but I'm not taking that chance in general.
Any block cipher can be brute-force broken given enough time and enough money. They question you have to ask is the information protected valuable enough to be worth spending the time and money on? Does someone really want to dedicate a several million dollar machine for several years to break a 2^64 strength-cipher you used? That information would still have to be worth a decent portion of the cost of the machine after a few years of crunching.
In reality the most practical uses of OTP's are the situations where the added security of a OTP is more-or-less moot. If I'm in close physical proximity with frequent meetings, and it's only to a friend, the value of the data is low, and the odds that I'm going to have anything to say that I can't say next time I see them is also low.
It's larger organizations like banks, companies, and governments that are exchanging large volumes of information that make the fattest, juiciest targets for analysis and they can't deploy OTP's for all of their needs, there's just too much data to do so.
Are your secrets worth more than theirs?
The fundamental problem with practical use of one time pads is that you need a separate secure mechanism by which to agree upon the pad. And of course, to be absolutely secure that pad needs to be:
1) truly random
2) only used one time
3) as long as the data to be encrypted.
Those three are the assumptions about the pad required to reach absolute security that make OTP's impractical. If all three are not met, or the exchange is not secure, the security of the OTP is no longer absolute.
Most generation mechanisms that are truly random only generate the pad at one location. That will result in you needing to courier the pads to the party that will eventually receive your messages. If you can already securely courier the data of the pads, in most cases it makes sense to just courier the data itself.
Some alleged one-time pad systems that are practical use a password or short random secret fed into a PRNG to expand the key to the length needed as a pad. However the output of a PRNG is not truly random, and thus the security of the "unbreakable" one-time pad is reduced to the strength of the PRNG against prediction. Most PRNGs are weaker than brute-force analysis of a 2^128 key block cipher. Many PRNG's are actualy highly linear and very predictable (see some of the research on TCP sequence number prediction to see just how hard it is to get a PRNG that isn't trivially predictable.) There is EXTENSIVE cryptographic research pointing out how foolhardy it is to think that a PRNG extended key is as secure as a OTP, and thus unbreakable.
Another practical problem for OTPs is the storage of the pad itself. The pad is quite lengthy, at least as large as all the secure data you want to transmit before exchanging pads again, and needs to be stored in a secure fashion at both the sender and recipient's facilities.
One of the primary reasons for the creation of block ciphers and other symmetric encryption mechanisms is that they reduce the amount of data that you need to securely exchange into a relatively small key. That small key can then be used in the transfer of a significantly larger portion of data, and it is now possible the algorithm is weak, but at least the small keys make these ciphers by far more practical to use in real-world situations than a OTP.
Agreed, such devices tend to have poor ISNs, but then again, they are for home use, and the ports they serve only respond on the INSIDE. Outbound traffic passes thru with more-or-less the same ISN it started with.
Unless you don't trust people on your home lan, it's not much of an issue. Yes, it should be done right, but the only people that can exploit this are those within your network. If they are in your home, they can do much worse than hijack your session as you configure the router.
As for outbound traffic, if you connect to an outside website from an inside PC, it uses the ISN that the PC generated and doesn't change it or adds some simple fixed constant. It still retains all of the entropy of the original PC's ISN. Nobody from the outside should be able to connect to the configuration server in the "DSL router" device. Hence, nobody from the outside really sees the poor entropy of the DSLRouter's ISNs.
Only higher-end firewall products, ie: the cisco PIX, attempt to mangle the ISN generation as they translate hosts. Most of the simple products do not, and certianly none of the $100 DSL routers do.
Also good ISN generation is actualy important to more "commercial" grade routers, since these devices are sometimes deployed and administered remotely, generate tunnels, etc. Thus these routers/firewalls sometimes have exposed ports, or exposed client traffic on a public network as they are being reconfigured.
Of course, many are only configured localy, or over a local LAN, which makes the risk a lot lower, but also users on corprate lans are generaly less trusted than those in your own home.
I too know this is all a joke, however...
:)
:) Or maybe you should have been responsible enough to fix their security problems yourself before your account information got disclosed :)
By the phrase "You are responsible for maintaining the confidentiality of your password and account information." I don't believe Microsoft is requiring you to maintain confidentiality, but instead they are disclaiming any of their own responsibility if your password is disclosed. ie: if you give your password to someone else, don't blame us, we're not responsible.
Of course, other clauses probably give them the rights to shut down accounts which they realize have been comprimised. For security reasons, of course, MS clearly only wants to protect their users
It's also a bit amusing and twisted to realize that statement also means that if Microsoft is hacked and your password and account information are stolen, that's your problem, not Microsoft's. Clearly you should have been responsible enough to not give it to MS in the first place
Why not have a small IR beam sensor (you can buy the parts at most ratshacks) and have that set off a buzzer/siren. Position the beam sensor pair within range of motion of her hand so all she needs to to is interrupt the beam with her fingertip.
Ratshack even used to sell a larger-scale version of this as a door entry bell. You placed the unit and a reflector on either side of a doorway and anytime someone walks through the beam a chime sounds. Most ratshacks had these set up and operating to alert the salespeople to incoming customers during off-hours.
You might be able to find a pre-made version of this device on a small scale for detecting cabinet openings, or as a small portable "hotel room alarm" but most of these kinds of devices will not use this mode of sensing. (most cabinet alarms sense the light pouring in from the room into the cabinet, and most hotel alarms hang on the doorknob and sense being rocked around with a mercury switch.)
I wouldn't say it secures *nothing*. In fact, I'd say it secures a lot of things many people don't even think about. But you are right, it's not as strong in the "prevent the buffer overflows" category, and most of the things it does a good admin would do by hand anyway.
It's got some pretty good file permission changes that work very well for server environments. And yes, file permissions really do matter. Even on the simplest level it will ask you to remove SUID permissions from ping, dump, traceroute, at, etc. I know for sure there's been at least one local user -> root user exploit for dump that would be foiled if it were non-suid. There was even one this year for at which allowed the same privilege elevation on RedHat versions prior to 7.2:
http://rhn.redhat.com/errata/RHSA-2002-015.html
Of course, a good admin should go through and audit which files are SUID him or herself and kill off ones which aren't used by non-root users. But this makes it a bit easier.
And yes, removing the SUID bits does make fewer commands available to non-root users, but let's face it, do non-root users really need to be able to run traceroutes and backups from your webserver?
The only major objection I have is that Ars is presenting some WEP problems as being RC4 problems ie: that RC4 is broken and cannot be secure if implemented properly. "The main problem with WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure." I'd change that to read ".. has been proven insecure if research notes regarding these problems are ignored."
They claim the RC4 algorithm itself is broken, which it is to some degree, but there's lots of information on how to avoid these problems that was available prior to the design of WEP. I also dislike their implication that RC4 inherently uses a 24 bit IV, that was an IEEE decision, RC4 can use an IV that's as large as you want.
RC4 is reasonably secure when implemented correctly, but IEEE ignored the very well known and clearly stated fact that when using RC4, keys must not be re-used for the same data. And that's not surprising, block ciphers are greatly weakened by such things too, which is why anyone in their right mind uses a decent sized IV. RC4 is weaker to key reuse than block ciphers because of its design, but that was a well known fact prior to the design of WEP.
Weak keys are a genuine weakness in RC4. However, they too are well documented and can be easily detected and skipped prior to use. The fact that WEP uses a 24bit IV makes it particularly easy to create a table of IVs that weak, making this problem significantly worse. A great paper on RC4's weak keys, and how to avoid the problem, was posted to sci.crypt in 1995:
http://marcel.wanda.ch/Archive/WeakKeys.txt
So all the weaknesses in WEP that stem from the use of RC4 as an encryption algorithm were well documented, and methods of avoiding them resulting in weaknesses were well known, but the IEEE chose not to heed them. They were trying to make something "secure enough" and traded off things like using a short IV without consulting the cryptographic community about the implications.
Hindsight is 20-20, but I can't exactly call these RC4 flaws. I mean, if you had a power tool and you ignored the warnings printed in the manual, would you blame the tool when it fails?
Using a short IV is clearly an implementation flaw, the fault of WEP not RC4. IEEE wanted to save a few bytes of overhead and purposefuly chose a short IV. The weak keys are a flaw in RC4, but just generating a few bytes and discarding prior to using the key helps reduce the scope of this attack dramaticly. Even better is to detect and avoid the use of the weak keys in the first place, or do both. Since this was widely known when WEP was designed, I consider it to be a implementation flaw in WEP as well, albeit one that stems from a weakness in RC4.
Yes, but in this country there is a concept referred to as negligence. I am not a lawyer, but if my understanding of the law is correct if you are knowingly negligent in securing a resource which is known to be able to cause harm (monetarily or otherwise) when stolen, you are in some manner liable for the damages caused. Correct me if I am wrong, but if I ran a gun store and refused to lock the door when i left at night, despite being warned that kids were walking in and stealing the guns, I would be guiltily of manslaughter (at least) if one of those guns was used in a murder. Given that I premeditatedly chose to keep the store unlocked despite being advised of the risks, it might even be 1st degree murder (I'm not sure, IANAL as I already said).
I am not an "expert" in the field of mailserver security either, but it is my opinion that this is a cut-and-dry case of negligence on Johns part, and I am disgusted that he would go so far as to try to abuse the first amendment in this manner.
This security problem is so well known, and so well documented there's even an RFC on the matter, RFC 2505. And while this RFC is a description of current best practices, not a protocol requirements document, the list of recommendations under section 2 specifically states:
1) MUST be able to restrict unauthorized use as Mail Relay.
Don't believe me, go here:
http://www.ietf.org/rfc/rfc2505.txt
This implies to me that despite the existence of technical methods to solve this problem (SMTP authentication for one), and having been advised of the impact this is having on others, John Gilmore is bent on ignoring industry standard practices for properly securing a mailserver. Even Yahoo can figure out how to configure their SMTP server to use authentication, and the eudora mail client that Gilmore specifically mentions on his page is capable of using SMTP auth (I know, I use eudora and have a yahoo account).
So how exactly is this a matter of free speech and not an attempt to contain the damage caused by a negligently configured mailserver operated by an administrator who is not ignorant to the industry standard methods of preventing the problem, and appears to be merely ignoring such standards for the sake of convenience? Sounds a lot like a "well, locking my store is a hassle because I have to remember to bring my keys with me when I go to work so I leave my gun store unlocked" argument. (admittedly the damage caused by this is much lower than a gun store, but it is fundamentally the same argument he's making)
On his page Gilmore also makes the argument that the filter Verio has placed upon his internet connection is sufficient to stop the damage, this gives them no grounds to terminate him. What I believe that Gilmore is failing to realize is that he is placing the responsibility for correcting his own security problems on Verio. Now, due to the negligence of one of their customers, Vero has to maintain a filter to ensure that customer does no damage, and you could even make the argument that if the filter fails, now *they* are negligent and liable for the damage caused. If I ran and ISP I certainly would not want that liability.
Now Verio is considering not disconnecting him because he's agreed to do some form of rate limiting? Sorry, this is not the proper solution to this simple problem.. it merely reduces the rate of damage caused to a less problematic level.
(yeah, I'll secure the gun cases so you can only take one gun out every five minutes, which will prevent someone from coming in and taking more than one gun at a time, because I still don't want to put a lock on my door, even though the lock is free and I can install it myself.)
I'm sorry Gilmore, you've been around the internet block several times more than I have, but I don't see how your arguments of free speech hold water. I'm also quite concerned that your actions are weakening the strength of the name of the EFF by associating them with a free speech argument which seems to consist of little more than baseless litigation. I expect legal cases with common-sense holes the size of Texas in them from the legal department of Amazon (patenting affiliation sales?) but I do not expect the name of the EFF to be associated with such frivolous matters.
Censorship? Bah! Get off dead center and secure your systems properly.
This new law is not about email opt-ins, under the new law companies can still spam VT residents into oblivion without opt-in. I feel your pain on spam, but that's got nothing to do with this law, and it makes your post offtopic (by accident).
The law prohibits financial companies from sharing information they have about you with other companies without your consent.
It does not stop them from sending you email, junkmail, and telemarketing calls themselves. It does stop them from sharing the contact info they with their "trusted business partners" (read: anyone willing to pay money for an address list) unless they have your permission.
So as best I can tell, the biggest impact is if you live in VT, your bank (or other financial service provider) can't sell lists of addresses of people with "accounts in good standing" to credit card companies. This removes a profit center from the bank, causing them to up service fees to compensate, but also removes unwanted credit card offers from your mailbox and phone service.
Well, I tend not to put much credit into the "physical stuff" of a bank. If a bank goes under the value of their "physical stuff" will likely be very insignificant compared to the potential debt of the company. Remember the S&L scandals of the 80's? Personally I find the fact that a bank is federally insured much more reassuring than their "physical stuff". (Paypal is not a bank and not insured as one) Even FDIC has its limits, but it provides far more backing than the paltry physical assets of most banks.
think about the assets of a small-mid sided bank office (wild guesses here, I'm not a banker):
Commercial building maybe 500k, but is likely leased
Computer equipment: 200k
office furniture, pens, etc: 100k
specialized facilities (safe deposit vault): 500k
So their physical assets might be as much as 1.2 million, supporting moderate number of small business accounts (200 maybe) and a decent number of personal accounts (3000 maybe), again, more guesses. Assuming an average value of these accounts at $2000 each (guessing) that's 6.4 million. And that's just the deposit side of things, not the loan side. Even with the wild inaccuracies of my guesses, it's not hard to see that the physical assets are not likely to match up much against the value of the accounts.
Well, I don't know about chip, but when I file an abuse complaint, I tend to include the entire spam message so that they can verify the content as a commercial email. They don't have to read the whole thing if they don't want.
;)
These days with MS outlook html spam mails, 50k is a bit large, but not unheard of. Admittedly my largest spam for today is 18k, but I've gotten some whoppers before. (On the 26th I got a 42k byte spam.)
If @homes AUP department can't handle a single 50k email, they've got problems
If you just want to know what certian attacks look like, I might suggest going to snort.org and looking at the Intrusion detection rules they have. (downloads, snort-rules-current)
While this isn't a pretty-pictures way of doing it, they do contain a lot of signatures for suspicious packets. Be ready for information in this kind of format:
alert tcp $EXTERNAL_NET !80 -> $HOME_NET 21554 (msg:"BACKDOOR GirlFriendaccess"; flags: A+; content:"Girl"; reference:arachnids,98; sid:145; classtype:misc-activity; rev:3;)
Which means a tcp segment from an outside machine on port 80, to an inside machine on port 21554 with the text content "Girl" might be an attempt to access the "Girlfriend" trojan horse.
Better yet, why not install and run snort on a low-end box and let it identify the wacky ones for you. I run one on a console only OpenBSD box with a p-90 and it monitors a T1 just fine. Another runs on a 486-120 under console-only linux.
There is even a Window$ version for those that prefer that platform.
I once had a cheap espresso maker shipped to me via UPS a couple of years ago (95-96). Admittedly the unit was shipped in it's store-shelf box, which is under UPS specs for box strength. (UPS used this as an out to avoid damage liability)
The damage done to the espresso maker was so severe I still cannot fully explain it to this day. The Espresso maker consisted of a rather sturdy rigid plastic housing and a very thick metal pressure jar inside. The base of this unit could clearly support in excess of 150lbs static weight without damage to the plastic housing.
Upon arrival the box height was reduced 4", the plastic housing of the unit was significantly crushed inside and the plastic control knob was sheered off. Strangely the glass decanter was unscathed.
Given the light weight of the device, a drop from a warehouse height ceiling (20-30') onto concrete would not have been sufficient to cause this level of damage to the device. My best guess is a heavy (>100lb) package was dropped onto this box from a moderate (3-4') height. ie: someone strong threw a very heavy object into a truck or onto a pile of boxes, crushing everything in its path.
Since this experience my rule-of-thumb for UPS shipping expectations are:
1) expect your package to have to withstand being thrown 15' into a hard object if it is light, 5' if it is >100lbs
2) expect it to have to withstand someone dropping a large heavy package onto it.
The bottom line is to expect that some UPS handlers really don't seem to care, they just throw stuff into piles and onto belts. Armor your packages accordingly. I at minimum use double-layer heavy gauge cardboard, even on light items. (sometimes I kludge this by cutting panels and lining the inside of the box with them and gluing them in place. As long as they are an exact fit you still gain crush resistance.) Heavy items may be wooden or plastic frame reinforcing the inside of a cardboard box, or stronger construction.
The "standard" tarball linked under "getting source" on the OpenSSH page is for OpenBSD and does not have a configure script, just a installer.
If you download OpenSSH for a non OpenBSD box, make sure you pick the portable version. (under operating systems click on your operating system, or go to: http://www.openssh.com/portable.html).
I agree, it's quite ridiculous that this post has been moderated up. It's purely off-topic.
I've actually USED paradigm C++, along with paradigm link and locate tools. It's for embedded application development. (ie: raw rom hanging off an x86 processor bus with no bios (you actually run where a BIOS would be), no OS, etc). The dev tools themselves run on ms-windows.
This tool has little to do with multithreading, in fact I don't belive it contains a thread library at all. (I could be wrong, but I never saw one and it's not a listed feature) It supports real mode, and if you're x86 can do it, protected. It will target as low as 80186's and NEC v## processors.
It also has nothing to do with UNIX. It's for people building non-pc x86 based systems that have no BIOS and no OS. It's for bare-metal embedded c++. You can't even run the IDE on UNIX, much less the target.
They have a site at devtools.com, visit if you're bored, see how much Multithreaded Unix support they have...
My personal opinions of this software aren't very high, but mostly because my opinion of x86 for raw-soldered embedded is pretty low. The product itself is relatively well written.