It's not that stupid imo. With pre-processor and other compile time trickery you can get a big kernel or a small kernel. But you still have the footprint of a massive codebase.
If reliability is your goal, how do you go about regression testing all of the possible combinations that may or may not have been chosen at compile time?
I think this is only going to get worse with multi-core cpu advancement. A monolithic kernel is destined to be a giant pita.
Isn't this problem only going to get worse? The architecture of bolting everything into the kernel (as a loadable module or not) will eventually collapse under its own weight.
I can only imagine the mutex nightmares Linux will have when 64 cores become the standard.
At what point do you sacrifice percentage points of performance for huge savings in complexity and huge increases in stability and maintainability?
I'd put my money on a microkernel revival in the near future.
Do you really think building a system with no record of credit card transactions is better?
I'm not talking about storing CVV values, but I would be inclined to keep the core details (credit card number, signature imprint etc) around until I got paid by VISA/MC and/or the refund period expired. Granted, appropriate authorization and encryption security needs to be in place as I'm not in favor of keeping all this stuff in clear text.
If you are a merchant and you store none of these details, you open yourself up to all kinds of fraud.
Obtaining the original data is hardly the point of breaking the hash. You can't recreate the Illiad from 2048 bits for God's sake.
An attacker's goal would be to substitute something else for the original data and make you trust it.
However, if the algorithm is weak enough to allow a collision to be manufactured deterministically, then an attacker can craft a substitute message that returns the same hash. Think appending a junk file to the end of an archive to force the same hash.
If you don't believe me, post a few public IP addresses of your corporate network and see how many new friends you make. I'm guessing alot of people could use the extra disk space.
I have Comcast and have no problem using sendmail to forward my outbound mail through their mail servers. My servers are Solaris and AIX but I expect Linux would work as well.
Total sendmail novice here, but about ten minutes of googling around turned up some
examples.
I'm not advocating a total ISP lockdown (we all like bittorent don't we?) but wouldn't it make more sense to block this port by default and open it upon request?
Quite a long time ago I was told to troubleshoot a problem on a system we had sold. It was an Old-Time(tm) PC-DOS system with no network or modem so all I could do was get on the phone and ask the person to type for me and pull up some logs.
The conversation went something like this...
Me: ok, do you see a DOS prompt?
Customer: yes!
Do you see a "c:\"
Customer: yes!
Me: type "cd logs"
Customer: It says "Syntax error"
At this point we repeated the exercise several, several times. I was completely stumped as to why we couldn't get to the logs directory to even start to figure out the real problem.
Things escalated and my boss put me on a flight to go fix the system. I went down to have a look and in five minutes I was kicking myself watching the customer type:
Is this a symptom of having too much code in the kernel?
At what point do we declare that the need for supporting a variety of devices and a more stable kernel overrides the desire to eek out a few more percentage points of performance?
"Windows-like" uptime is scary. Wasn't the 2.5.x series supposed to be the development tree?
If you plan to cluster, be sure to evaluate your use of session. If you intend to replicate your session objects across each instance of the cluster, they will need to be serializable so that the container can move them around.
From past experience, you will need to consider the size of these objects as well -- if each session footprint is large, you may have some scalability limits.
As an alternative, you can choose to not cluster the session objects and leave them on the original container. To do this, your front end router must ensure that the sessions return to the original container via a cookie or some other means.
Also, consider eliminating any file-based storage on the cluster. Use JDBC for queues and logs. In this way, if you lose an instance of the cluster, your data will still be safe in your database (assuming you have a HA solution for your database)
I think you are a little off point when it comes to poker.
Cheating at casino poker is different than trying to rip off a slot machine or a blackjack table. In a poker game, the casino gets its commission ("the rake") everytime, up front. The cheats aren't trying to rob the casino; they're going after the other players.
Certainly the casino has an interest in maintaining a fair game, but it is safe to assume that only a minor percentage of the total security resources are dedicated to catching poker cheats. Casinos are going to spend the majority of their dollars protecting the house money, not the players'.
The good news is that there is not enough money in a low-limit casino poker game to interest most serious cheaters. However, winning one extra pot a night in a high-limit game could prove very profitable. High limit players aren't going to trust the casinos implicitly to weed out the cheats.
Not to start a flame war but why not just fix CVS?
If the svn feature set isn't that much richer than cvs, why bifurcate the developer community? Does the fame and glory associated with having a new shiny program outweigh the adoption hurdles?
I am all for having choices and options -- I love it, but isn't a fundamental tenet of Open Source having the ability to improve and amend a program? A complete rewrite sounds more like a closed source reaction.
But seriously, I am just a long time CVS user who is patently lazy and wants all of these neat new features in CVS without any migration or disruption or effort.
As a fresh faced developer out of college, I was given an opportunity to build a real-time data acquisition system using OS/2 for a long since gone company, http://www.teknivent.com.
OS/2 had great features for developers, a rich presentation API (2D of course), preemptive multitasking, GPIB drivers, detailed API documentation, etc, etc. On the negative side, our app + OS/2 needed 4MB of RAM and RAM was $1000 per MB at the time.
I still remember demoing our software for the first time at a trade show. IBM came by with an army of suits to see the demo, first time seeing a commercial OS/2 application I suppose. I still remember one of the guys asking me how many lines of code it was. My answer?
10 -- really really long lines.
Jim
P.S. For OS afficionados, I would recommend The Design of OS/2 by Deitel. This ten year old book still rocks!
Slashdot Mirror
If reliability is your goal, how do you go about regression testing all of the possible combinations that may or may not have been chosen at compile time?
I think this is only going to get worse with multi-core cpu advancement. A monolithic kernel is destined to be a giant pita.
I can only imagine the mutex nightmares Linux will have when 64 cores become the standard.
At what point do you sacrifice percentage points of performance for huge savings in complexity and huge increases in stability and maintainability?
I'd put my money on a microkernel revival in the near future.
If you let me code and install my own output drivers, you will not prevent me from obtaining an unencumbered signal.
I'm not talking about storing CVV values, but I would be inclined to keep the core details (credit card number, signature imprint etc) around until I got paid by VISA/MC and/or the refund period expired. Granted, appropriate authorization and encryption security needs to be in place as I'm not in favor of keeping all this stuff in clear text.
If you are a merchant and you store none of these details, you open yourself up to all kinds of fraud.
Both are best enjoyed when drinking heavily.
whybother
Emulating a Centris 650 running Mac OS X at 2.5 Ghz.
Obtaining the original data is hardly the point of breaking the hash. You can't recreate the Illiad from 2048 bits for God's sake.
An attacker's goal would be to substitute something else for the original data and make you trust it.
Right, in theory collisions are possible.
However, if the algorithm is weak enough to allow a collision to be manufactured deterministically, then an attacker can craft a substitute message that returns the same hash. Think appending a junk file to the end of an archive to force the same hash.
Can you see the problem with that?
Use a mail forwarder.
http://www.myus.com/
If you don't believe me, post a few public IP addresses of your corporate network and see how many new friends you make.
I'm guessing alot of people could use the extra disk space.
I have Comcast and have no problem using sendmail to forward my outbound mail through their mail servers. My servers are Solaris and AIX but I expect Linux would work as well.
Total sendmail novice here, but about ten minutes of googling around turned up some examples.
I'm not advocating a total ISP lockdown (we all like bittorent don't we?) but wouldn't it make more sense to block this port by default and open it upon request?
The conversation went something like this...
Me: ok, do you see a DOS prompt?
Customer: yes!
Do you see a "c:\"
Customer: yes!
Me: type "cd logs"
Customer: It says "Syntax error"
At this point we repeated the exercise several, several times. I was completely stumped as to why we couldn't get to the logs directory to even start to figure out the real problem.
Things escalated and my boss put me on a flight to go fix the system. I went down to have a look and in five minutes I was kicking myself watching the customer type:
I never felt like a bigger idiot.
Apple's ProDOS had long filename support back when Microsoft's manuals came in 3 ring binders and thw Windows game of choice was Reversi.
ZZ
At what point do we declare that the need for supporting a variety of devices and a more stable kernel overrides the desire to eek out a few more percentage points of performance?
"Windows-like" uptime is scary. Wasn't the 2.5.x series supposed to be the development tree?
ZZ
What if I reply to someone's usenet posting and cc: with email (as requested). Then this a-hole decides to pilfer my escrow?
Why is it so hard to create a solution that prevents forged headers?
Every other solution seems like an atomic baloney slicer.
If you plan to cluster, be sure to evaluate your use of session. If you intend to replicate your session objects across each instance of the cluster, they will need to be serializable so that the container can move them around. From past experience, you will need to consider the size of these objects as well -- if each session footprint is large, you may have some scalability limits. As an alternative, you can choose to not cluster the session objects and leave them on the original container. To do this, your front end router must ensure that the sessions return to the original container via a cookie or some other means. Also, consider eliminating any file-based storage on the cluster. Use JDBC for queues and logs. In this way, if you lose an instance of the cluster, your data will still be safe in your database (assuming you have a HA solution for your database)
Cheating at casino poker is different than trying to rip off a slot machine or a blackjack table. In a poker game, the casino gets its commission ("the rake") everytime, up front. The cheats aren't trying to rob the casino; they're going after the other players.
Certainly the casino has an interest in maintaining a fair game, but it is safe to assume that only a minor percentage of the total security resources are dedicated to catching poker cheats. Casinos are going to spend the majority of their dollars protecting the house money, not the players'.
The good news is that there is not enough money in a low-limit casino poker game to interest most serious cheaters. However, winning one extra pot a night in a high-limit game could prove very profitable. High limit players aren't going to trust the casinos implicitly to weed out the cheats.
hmmm...check the date on the RFC..methinks my yank is being chained. ZZ
If the svn feature set isn't that much richer than cvs, why bifurcate the developer community? Does the fame and glory associated with having a new shiny program outweigh the adoption hurdles?
I am all for having choices and options -- I love it, but isn't a fundamental tenet of Open Source having the ability to improve and amend a program? A complete rewrite sounds more like a closed source reaction.
But seriously, I am just a long time CVS user who is patently lazy and wants all of these neat new features in CVS without any migration or disruption or effort.
Cheers!
As a fresh faced developer out of college, I was given an opportunity to build a real-time data acquisition system using OS/2 for a long since gone company, http://www.teknivent.com.
OS/2 had great features for developers, a rich presentation API (2D of course), preemptive multitasking, GPIB drivers, detailed API documentation, etc, etc. On the negative side, our app + OS/2 needed 4MB of RAM and RAM was $1000 per MB at the time.
I still remember demoing our software for the first time at a trade show. IBM came by with an army of suits to see the demo, first time seeing a commercial OS/2 application I suppose. I still remember one of the guys asking me how many lines of code it was. My answer?
10 -- really really long lines.
Jim
P.S. For OS afficionados, I would recommend The Design of OS/2 by Deitel. This ten year old book still rocks!