The discussion in itself is off-topic. In the real world no continuous magnitude can be exactly measured nor represented. There is nothing as "exactly 0.1 seconds". Any physical quantity is an approximation (like the numbers in digital computers.) The problem was in the system design that apparently (and incredibly) didn't account for that.
> such as not clicking links in the occasional spam email which passes through filters, avoiding suspicious websites,
Just setup a daily CRON job to send an email with a link pointing to a page in your web server that shows:
YOU CLICKED THE BAD LINK. YOU'RE AN IDIOT. NEXT TIME WE'LL CUT YOUR SALARY.
For the email subject, just collect a handful of common spam phrases, like "Tired of seeing disappointed faces on women when they pull down your pants". Problem solved.
> I would like to first see a thriving undersea settlement - the key to that being a civilian population including children
Good point. Yet I think there is a key difference: from any undersea city, people can always escape with standard technology, so they're not really forced to think out of the box better ways to adapt to that environment.
> Doesn't the lack of plentiful native species of edible plants and drinkable water mean that we can say it's impossible to live on Mars?
With the same argument, people never could have colonized and transformed a lot of terrestrial territories. Plants were transplanted where the native ones were not appropriate; and distillation of water is not very advanced science.
> Self adaption in the arctic was made much easier by the fact that there was breathable air and fish in the sea.
Of course Mars will be lots of times more difficult, but the first Eskimos didn't have our current technology.
> The only point of sending men to Mars is to prove the point that we can send men to Mars.
Why we assume that those men/women will not figure out some better ways to survive, or develop better technology than in our terrestrial labs? To me the point is let a croud of people try to self-adapt (like the explorers in the artic, for example.) Since we never lived in Mars, we can't say that is not possible (despite the data and failures of the robots sent before.)
Of course a good terrestrial food/water supply is in order in the first years (decades?).
I remember when HP got the Compaq tru64 Unix business; they (supposedly) tried to maintain both Unixes for a while, and ended with a big (forced) migration to HP/UX servers.
In the end, I think the business was good for them: more corporate clients. It's reasonable to expect the same with the (bigger) Sun/Solaris case.
I think that many people feels that a Big and Expensive (even OSS bla bla) product should take for ever to load.
And most people didn't realize that all the apps they run just need a Web Container. Of course, there are exceptions, but apparently a lot of developers think that for whatever reason they need support for EJBs, JMS, JTA, Clustering, etc... for their JSP/JSF/Struts projects.
Yet I have a sense of fear that some day a chinese hacker can access and take control of my (chinese) IPV6 enabled microwave oven, and kill me with the radiation:)
Yes, almost nobody configure the NAT because that's automatically assumed by the brand new routers. Some day we could have DSL routers that work the other way.
Now, another objection to the firewall approach is regarding the "failure case": if the REJECT rule is removed/lost, that will leave my machines as direct (directionable) targets from the outside. If the NAT fails, the consequence is that the machines just can't navigate. I prefer the last option.
God points; you're pretty right regarding security patches. I hope those ideas could be implemented in the Debian package manager, since currently many little security fixes carry the update of several full packages because of the dependency rules. Of course this is a different but related problem.
>There's also the fact that (a) there's little motive to use full-blown optimized compilation on most of an application's code (best save it for the 20% of the code that runs 80% of the time),
AFAIK, the distributors usually apply the same kind of optimizations to the 99% of the code, just because it's easier. But of course the 80/20 rule is valid.
1) The bulk of many (most?) software packages are resources, not executables 2) A lot of the executables is a lot of linker/DLL overhead, specially the smaller ones 3) The optimizers (I think) remix the assembly instructions, so small changes in the program logic result in a lot of changes in assembly, ergo, in machine code. The best solution in terms of BW remains sending diffs in high level source code.
Ok, the OSS names are stupid and ugly, but you just run the thing, and understand its purpose.
Now, go to the IBM web site and try to understand the "Rational" products... at least try to discover the very reason of their existence. It you're brave enough, you will download 80 Mb of an "intelligent installer" which in turn will download 2Gb of the real software. Often there will be no instructions about how to execute it, but you'll be referred to some broken IBM hiperlink for up to date instructions...
The main drawback I see in current certifications and even full "security careers" is that they see the subject as a tool for approving audits. So the "professionals" end doing a lot of paperwork that helps the organization to comply with some kind of standards, but technically remains totally insecure. Sadly, that's my experience from the big companies I had opportunity to work into.
Slashdot Mirror
The discussion in itself is off-topic. In the real world no continuous magnitude can be exactly measured nor represented. There is nothing as "exactly 0.1 seconds". Any physical quantity is an approximation (like the numbers in digital computers.) The problem was in the system design that apparently (and incredibly) didn't account for that.
> such as not clicking links in the occasional spam email which passes through filters, avoiding suspicious websites,
Just setup a daily CRON job to send an email with a link pointing to a page in your web server that shows:
YOU CLICKED THE BAD LINK. YOU'RE AN IDIOT. NEXT TIME WE'LL CUT YOUR SALARY.
For the email subject, just collect a handful of common spam phrases, like "Tired of seeing disappointed faces on women when they pull down your pants". Problem solved.
Bad analogy. The article(?) is about SAVING money, not money bleeding.
> All it takes is that one guy that says everything is easy to influence everyone's brain to under-estimate a project.
Not exactly.
What TFA says could be translated like:
YOU analyze some (software?) project, and decided (maybe correctly or not) that this is easy.
Next you analyze other totally unrelated task, for example, running 2 km, and you will more probably underestimate the effort (and the other way too.)
It's some kind of auto-suggestion with an interesting prove of correlation.
Water in small doses is absolutely needed for humans. Water in high doses get them drowned.
The same apply to cholesterol and most substances.
What's new here?
> chances that your code won't need very much porting to work with the C++ standard library of tomorrow.
Don't worry. For the C++ standards committee people, "tomorrow" means what ten years is for the rest of us.
> For an emulator tho you can populate the memory before starting, so you dont really need the BASIC.
Several games (like the popular Sid Meier's Pirates) were a mix of Basic and machine code.
Of course, the "game" may include the BASIC rom files provided there is some standardized way to install them.
> I would like to first see a thriving undersea settlement - the key to that being a civilian population including children
Good point. Yet I think there is a key difference: from any undersea city, people can always escape with standard technology, so they're not really forced to think out of the box better ways to adapt to that environment.
> But in fact, the article quotes IBM claiming the announcement of the acquisition is what drove people to IBM;
From the article, I read that IBM is taking the Sun' server market from Sun; the developers are going anywhere they find better.
> Doesn't the lack of plentiful native species of edible plants and drinkable water mean that we can say it's impossible to live on Mars?
With the same argument, people never could have colonized and transformed a lot of terrestrial territories. Plants were transplanted where the native ones were not appropriate; and distillation of water is not very advanced science.
> Self adaption in the arctic was made much easier by the fact that there was breathable air and fish in the sea.
Of course Mars will be lots of times more difficult, but the first Eskimos didn't have our current technology.
> The only point of sending men to Mars is to prove the point that we can send men to Mars.
Why we assume that those men/women will not figure out some better ways to survive, or develop better technology than in our terrestrial labs? To me the point is let a croud of people try to self-adapt (like the explorers in the artic, for example.) Since we never lived in Mars, we can't say that is not possible (despite the data and failures of the robots sent before.)
Of course a good terrestrial food/water supply is in order in the first years (decades?).
I remember when HP got the Compaq tru64 Unix business; they (supposedly) tried to maintain both Unixes for a while, and ended with a big (forced) migration to HP/UX servers.
In the end, I think the business was good for them: more corporate clients. It's reasonable to expect the same with the (bigger) Sun/Solaris case.
> A Jboss server needs here one MINUTE to load.
I think that many people feels that a Big and Expensive (even OSS bla bla) product should take for ever to load.
And most people didn't realize that all the apps they run just need a Web Container. Of course, there are exceptions, but apparently a lot of developers think that for whatever reason they need support for EJBs, JMS, JTA, Clustering, etc... for their JSP/JSF/Struts projects.
Knuth doesn't mention assembly.
Of course, your scenario will work too.
Yet I have a sense of fear that some day a chinese hacker can access and take control of my (chinese) IPV6 enabled microwave oven, and kill me with the radiation :)
Yes, almost nobody configure the NAT because that's automatically assumed by the brand new routers. Some day we could have DSL routers that work the other way.
Now, another objection to the firewall approach is regarding the "failure case": if the REJECT rule is removed/lost, that will leave my machines as direct (directionable) targets from the outside. If the NAT fails, the consequence is that the machines just can't navigate. I prefer the last option.
> What security does it provide that a REJECT ALL firewall rule wouldn't?
The security that most users don't have any idea about how to configure a REJECT rule, even if they have a firewall at all.
> Maybe that's a sign of something.
Please, get the idea! That link needs Firefox >= 3.6 to be functional.
Twice the distance? so I'll have 4 times the routers to steal internet access?
> Overall I think Sun offers superior products, but their customer support system is rather terrible.
I also believe that Sun offered superior products, but too overpriced for the market of the end of the 90s.
> Instead they should have focused their energies behind their flagship SPARC lines and actually produced a processor of their own
Yes... but for sure, the sale price would be at 20k/cpu for a performance similar to a Xeon; that's not competitive.
God points; you're pretty right regarding security patches. I hope those ideas could be implemented in the Debian package manager, since currently many little security fixes carry the update of several full packages because of the dependency rules. Of course this is a different but related problem.
>There's also the fact that (a) there's little motive to use full-blown optimized compilation on most of an application's code (best save it for the 20% of the code that runs 80% of the time),
AFAIK, the distributors usually apply the same kind of optimizations to the 99% of the code, just because it's easier. But of course the 80/20 rule is valid.
I'm not sure about the benefits.
1) The bulk of many (most?) software packages are resources, not executables
2) A lot of the executables is a lot of linker/DLL overhead, specially the smaller ones
3) The optimizers (I think) remix the assembly instructions, so small changes in the program logic result in a lot of changes in assembly, ergo, in machine code. The best solution in terms of BW remains sending diffs in high level source code.
Ok, the OSS names are stupid and ugly, but you just run the thing, and understand its purpose.
Now, go to the IBM web site and try to understand the "Rational" products... at least try to discover the very reason of their existence. It you're brave enough, you will download 80 Mb of an "intelligent installer" which in turn will download 2Gb of the real software. Often there will be no instructions about how to execute it, but you'll be referred to some broken IBM hiperlink for up to date instructions...
The main drawback I see in current certifications and even full "security careers" is that they see the subject as a tool for approving audits. So the "professionals" end doing a lot of paperwork that helps the organization to comply with some kind of standards, but technically remains totally insecure. Sadly, that's my experience from the big companies I had opportunity to work into.
A beautiful but missing chapter would be titled "Why security standards and certifications are mostly useless (even counterproductive.)".