No, it was the fabled "Konami Code" which worked in virtually all Konami games (it made a noise in Double Dribble, but I never did figure out what it enabled). The one use I remember was 99 lives in Contra.
You mean those fellows who can't buy pants that fit right?
Hot Water Heater is a bit more specific than it needs to be, and is moderately inaccurate since it can also be set to make water merely warm. Despite being these things, its still not redundant.
I think I'll add it to my list of annoyingly specific phrases, like "tuna fish" and "ink pen".
The poster should be ashamed of attempting to mock an English faux pas without first veryfing the veracity of the faux pas.
Fedora Core Release 3 is a noun. The verb "to release" conjugated into the past tense of "released" was then applied to the noun Fedora Core Release 3. This is entirely correct and non-redundant. The fact that the noun uses the word release in its name has nothing to do with having the past tense action "released" performed upon it.
Also, a "Hot Water Heater" is non-redundant as well. Hot Water does not, in my universe, magically instantiate itself as hot water. Instead it starts out as water, is heated in a vessel of some sort (mine is a metal cylinder lined with glass), then held at temperature until requested somewhere downline in the plumbing system.
Yes, this is very pedantic of me, however seeing something marked +5 funny when in fact its more like +5 ridiculous stupid, annoys the shit out of me.
I suppose there's the possibility the parent is an attempt humor. If so, well, perhaps it should've been funny.
Safety shots tend to require significantly more creativity than simply potting a ball. This is even more true in a game like snooker where there are up to 15 valid targets for the escape shot.
Is it possible? Sure, the AI already exists to play moderately decent safeties in games like Virtual Pool 3. The issue is that those games still lack the creativity necessary to play truly imaginitive safeties that human players use as a matter of course. Getting a machine to think creatively is much harder than wiring up some pneumatics to actuate a pool cue.
Even without mastering spin and such like given a high enough degree of accuracy it is likely that a very good execution plan could be calculated.
Unless spin and the like are mastered a great many execution plans are removed from the realm of possibility. There are fundamentally two things that separate pro level players from amateurs: Planning and cue ball control. Planning is a lot easier to learn than cue ball control, since you simply have to know whats possible. Executing that plan requires a very, very subtle blend of speed control, english, and cut angle.
Rather than searching forward like in chess a pool playing robot will have the luxury to decide which ball it wants to pot and then extrpolate back using simple newtonian mechanics.
This isn't entirely true. Yes, in 8 ball you know that the 8 ball is your final destination, however there are usually several paths there. In fact, the better the robot is at cue ball control, the more possible paths and the higher percentage they all become. Even worse are games like 3 cushion carom, or snooker, where the goals are less definable. Sure, in snooker the robot knows the final goal is to sink the black ball...but there're 15 reds with a required color in between, then 7 colored.
Furthermore, despite the stated goal of sinking any ball in any pocket from anywhere on the table, this just isn't feasible. Every game you see situations where certain balls are only possible in certain pockets, and sometimes this means the only shot available is a safety. In snooker this is particularly true, since a well played safety can score quite a few points with forced continues. Try teaching the robot to properly judge safety shots, since they require a decent understanding of whats possible, and the robot just can't use its own skills as a baseline.
In terms of complexity the two are roughly equivalent. They do all of the same functions, essentially, through two different interfaces.
Yes, its a small sample, then again I also didn't claim this was some large, statistically relevant sample but instead presented it as anecdotal evidence to support my opinion.
My point was that the posters argument was ridiculous. The dataset should absolutely be trimmed on the database server, thats the whole friggin' point of the database. Databases are good at refining the scope of the data set through where clauses, why reinvent the wheel on the app server side? The bandwidth argument is vaguely relevent then, but its still not the compelling reason.
Even the dataset just isn't that big. Besides which, stored procedures don't even enter into this. The dataset should be the same one way or the other, since query should return the same as the SP would.
What exactly do you think makes versioning stored procedures hard? Do you think developers go about changing SPs in a production environment with testing, committing the SP to CVS/Subversion/SourceSafe/BobsFilingCabinetOfSourc eContral? If so, please forward me the checksum of your resume so I can ensure I never hire you, work near you, or support anything you ever touched.
Bandwidth between the database server and your web server will be reduced - instead of passing huge queries across the link, you send a simple stored procedure call.
Don't be assinine. A modern production environment is running at least 100MBit Ethernet, if not 1GBit. A HUGE query, say 2500 characters, is 2.5KBytes. Gee, thats pretty rough.
Plus, PL/SQL is really easy to use and learn and is relatively portable across at least PostgreSQL and Oracle.
Easy to learn isn't an argument for or against a technology. That aside, relatively portable is logically equivalent to completely fucking unportable when translated from Marketing into English.
Stored procedures that execute the sme query as one sent over the normal client process usually execute faster. The DB server knows more about the query and the table structure, and therefor can optimize it better.
Having the queries in one place is also generally an advantage, and if the vast majority (or entirety) of your queries are in those stored procedures then migrating from one DB to another means NO messing with DB specific code (and every query ends up being DB specific if it does much of anything at all) except for the query developers.
The shop I work in has two main applications which access the same database. One is a web environment written entirely in Perl where all of the DB logic has been pushed into stored procedures, and then further abstracted into modules. Now migrating from one DB engine to another simply means rewriting the stored procedures from PL/SQL to TransactSQL (for example), and some minor modifications to the underlying modules. Then if we want to change the business rules for that data we can change the modules with only minor changes to the app logic.
Contrast this with a mega app written in C which has tons of queries directly in it, a minimum of stored procedures, and a constant stream of bugs because of the morass this has created. The app moves slowly, ponderously, and half the time wrongly.
Anytime I'd be called upon to architect something, I'd be pushing stored procs as much as possible. They're a logical extension of good, modular design.
There are other differences, particularly when it comes to Dimension vs. Precision. Find an SMP capable Precision, for example. And, if you're a corporate customer like I am, the Precision has more profit built in, so I can get free service upgrades, and things like the second proc for free (my dell rep misread my order and quoted me wrong. I then misread the quote and placed the order single CPU. When I pointed out my original email she sent me the processor gratis just to keep me happy. How can she do this? Profit Margin, thats how.)
Ever notice html is just a lot of text? Ever notice that tables are what lots of reports are done in? Ever think that instead of some bizarre loop generating nested table elements so the boss can comprehend the data, you could now just use form?
Just about anything written in sanskrit was written in it originally. Its been a dead language for an awfully long time now.
Also, English wasn't much spoken when a lot of the major scientific achievments were going on. As far as ground breaking discoveries go, the 1500s through the late 1800s were the boom time. You can only discover gravity once.
iSCSI is much more worthwhile since it has broad commercial support. MS, Sun, NetApp, EMC, HP, Cisco, Procom and more all have production quality iSCSI implementations, several of which are free for download/activation. While I can't find anything specific in a few minutes of searching, as far as I know iSCSI is an open standard, that at worst you just have to buy a copy of the IETF spec for.
Overall though, you're right. This OpenFiler is full of hype and lacking features. They claim to support more protocols than anyone else, which is a gigantic lie. They don't even remotely approach NetApp or Procom, or really even WinSAK based filers.
This is a little out of date, but an excellent book. Particularly for its coverage of using perl to interact with bind config files. A lot of the concepts are still very relevant, even if the implementation details have changed some. Any competent admin could pick it up, glean the new ideas and implement them in whatever form is comfortable.
"The message sequence issue (replay etc) is on the face of it rather bad, except that cipe is designed for carrying ip traffic. Repeating or removing udp messages is fine, and tcp messages do have sequence numbers. So I fail to see how that is a problem."
This is because you are dumb. Reread the posting to the mailing list to see the sort of attacks that replaying allows, especially in conjunction with the CRC-32 vulnerabilities that allow arbitrary packet insertion, packet modification, etc.
A quick example is a financial transaction system using CIPE. With no message sequencing I can replay packets that comprise a sequence of transactions which debit and credit accounts (whether they are accounts I want those transactions on, or just random ones is irrelevant), causing these transactions to repeat an arbitrary number of times. Obviously there'd be some additional safeguards that ought to be there to prevent this, but it is a failing of the protocol to not prevent message replay at a lower level. This is fairly basic protocol design.
Actually, I've seen a few lately from the polymorphic checks, and even more from the so-called heuristics that RAV has that detect new variants of old viruses.
You're quite right that overall count doesn't matter quite as much, however I'd not say that not having old patterns is unimportant. Just because it won't run on NT/2k/XP doesn't mean its not important to protect against. I have customers hitting my mail servers who still run truly ancient Windows versions, and they deserve protection too.
I haven't got the experience with Clam to judge their response time, but if you're running a for-profit mail server, you probably have a responsibility to your customers to ensure pattern updates are not only continuing today, but will continue tomorrow. The way to gaurantee that is to pick a vendor with a long term track record, and with some plan in place for tomorrow. Clam may have that, though it was built out of a previous open source AV solution which died, casting a bit of doubt on the whole concept.
What I'd really like to see is an open-source AV engine, and a for pay pattern source that works with that engine. The open source model works great for something like an engine, but not so great for something like pattern updates. One of the hardest parts of generating good pattern files is having a broad enough network of virus trap email accounts out there to catch them early, and get enough copies to get a reliable picture of the virus. Having a large test lab in which you can quickly test new pattern files against thousands of known viruses also helps.
Like I said in my first comment, or at least hope I said, Clam is an excellent choice for home users, but one that needs to be evaluated a lot more closely for commercial applications.
Clam's a nice engine and all, but look at the total number of viruses it recognizes. As of right this moment, its 9568 when using viruses.db and viruses.db2. The less than stellar commercial solution I use for now (rav antivirus) has definitions for just shy of 69K. That's a large difference. Better commercial engines include even more, along with sophisticated code for catching polymorphic viruses and as yet unseen variants of older viruses.
Clam is also not the most resource efficient or scalable AV solution, which when you're running a half million messages a day to almost a hundred thousand users starts to matter.
DirecTivo is technically more of an embedded system than a standalone Tivo, in that the DirecTivo is technically a satellite receiver, that happens to also have some linux stuff bolted on to do PVR functionality. The Tivo is just a nifty case around a PPC processor and a harddrive which has a TV-IN card.
A real embedded system is the controllers for, say, an automated automobile assembly station. The device builds cars, it just happens to have a brain composed partly of linux/qnx/tron/winCE/PalmOS to do the car building.
Its simple. IP address conservation should be a habit. Always pick the smallest usable subnet. Obviously that needs to take into account growth, but if you think your home network is going to run out of addresses on 192.168.0.0/16 then you should sober up before implementing.
Take the lowest MTBF for equipment in a server. Now divide by 100. With z/VM that MTBF is multiplied by the number of layers of redundancy, and is a rather large positive integer to begin with.
There's also the fact that with some basic scripting and use of some nifty open source tools (and the insanely fast inter-VM "networking") you can maintain one box, and all the rest just fall into line according to the frequency of your cronjobs. If you need to reboot, well, that's darn quick too, and requires zero remote power management (which also raises the MTBF, since power management always seems to fail at inconvenient and/or downright damaging times).
Excellent work my man, you just reinvented RAID-15, alternately known as 5+1, 1+5, 51, etc.
There are enclosures which do this automagically, with redundant controllers and backplanes, along with the ability to use global hot spares, etc so that in the event of a failure the drive is automagically rebuilt. Newer ones even use SMART to detect imminent failure and begin building onto a global hot spare prior to drive failure. Hell, NetApp claims the replacement drive usually shows up in the FedEx truck before the drive has a chance to fail with their SMART monitoring.
Your best bet though is to have two enclosures, each with two channels, each of which is a RAID-5 array. Then hook each enclosure up to two dual channel cards in two boxes, and do an active/passive HA setup, whereby the live box mirrors to the two enclosures (software or hardware, doesn't make much difference), and the standby doesn't even access them (using Fibrechannel you can force this, with SCSI you have to code around it with your HA scripts). The only danger here is in the event of an honest to god total catastrophic failure and both boxes crash. Using homebrew scripts, or the Linux HA project stuff, you're running a serious risk of "split brain" syndrome, where both boxes come up at the same time, and both consider themselves the master and try and fsck both parts of the mirror and fux0r everything.
I warn of this because I experienced it with a Veritas mirrored volume in a VCS cluster. 22 hours on the phone with support, 22 hours with my boss breathing down my neck, 22 hours of customers wondering when they'd be able to get their email because I didn't have the heart to tell them the real question was "if", not "when". Oh yeah, and that was my second day on the job.
The long winded answer, obviously, then is yes. You can do exactly what you described.
Some of us are, for a variety of reasons, stuck with SCO. We don't support them financially, morally, socially or in any other way, however that doesn't change that we have to run their OS for the time being.
Not every piece of hardware that is supported on SCO is supported on Linux, let alone supported well and with the same level of driver features.
For those of us in this position, its a scary thought to think that the community we could always depend on to do their best, people like the GCC community, are being pressured to act in a petty, punitive fashion. GCC dropping SCO support doesn't hurt SCO, it hurts people who might want to flee SCO. If I can't write code to GCC on SCO anymore, I'll need to go find another modern compiler for SCO (good luck, I know) and start writing with that compiler in mind. That means the FSF has achieved the exact opposite of their goal, in that they've forced me into proprietary software, and removed a tool for using even more free software.
Slashdot Mirror
No, it was the fabled "Konami Code" which worked in virtually all Konami games (it made a noise in Double Dribble, but I never did figure out what it enabled). The one use I remember was 99 lives in Contra.
Hot Water Heater is a bit more specific than it needs to be, and is moderately inaccurate since it can also be set to make water merely warm. Despite being these things, its still not redundant.
I think I'll add it to my list of annoyingly specific phrases, like "tuna fish" and "ink pen".
Fedora Core Release 3 is a noun. The verb "to release" conjugated into the past tense of "released" was then applied to the noun Fedora Core Release 3. This is entirely correct and non-redundant. The fact that the noun uses the word release in its name has nothing to do with having the past tense action "released" performed upon it.
Also, a "Hot Water Heater" is non-redundant as well. Hot Water does not, in my universe, magically instantiate itself as hot water. Instead it starts out as water, is heated in a vessel of some sort (mine is a metal cylinder lined with glass), then held at temperature until requested somewhere downline in the plumbing system.
Yes, this is very pedantic of me, however seeing something marked +5 funny when in fact its more like +5 ridiculous stupid, annoys the shit out of me.
I suppose there's the possibility the parent is an attempt humor. If so, well, perhaps it should've been funny.
Is it possible? Sure, the AI already exists to play moderately decent safeties in games like Virtual Pool 3. The issue is that those games still lack the creativity necessary to play truly imaginitive safeties that human players use as a matter of course. Getting a machine to think creatively is much harder than wiring up some pneumatics to actuate a pool cue.
Furthermore, despite the stated goal of sinking any ball in any pocket from anywhere on the table, this just isn't feasible. Every game you see situations where certain balls are only possible in certain pockets, and sometimes this means the only shot available is a safety. In snooker this is particularly true, since a well played safety can score quite a few points with forced continues. Try teaching the robot to properly judge safety shots, since they require a decent understanding of whats possible, and the robot just can't use its own skills as a baseline.
Yes, its a small sample, then again I also didn't claim this was some large, statistically relevant sample but instead presented it as anecdotal evidence to support my opinion.
As for proving anything, I didn't think I tried.
My point was that the posters argument was ridiculous. The dataset should absolutely be trimmed on the database server, thats the whole friggin' point of the database. Databases are good at refining the scope of the data set through where clauses, why reinvent the wheel on the app server side? The bandwidth argument is vaguely relevent then, but its still not the compelling reason.
Even the dataset just isn't that big. Besides which, stored procedures don't even enter into this. The dataset should be the same one way or the other, since query should return the same as the SP would.
Having the queries in one place is also generally an advantage, and if the vast majority (or entirety) of your queries are in those stored procedures then migrating from one DB to another means NO messing with DB specific code (and every query ends up being DB specific if it does much of anything at all) except for the query developers.
The shop I work in has two main applications which access the same database. One is a web environment written entirely in Perl where all of the DB logic has been pushed into stored procedures, and then further abstracted into modules. Now migrating from one DB engine to another simply means rewriting the stored procedures from PL/SQL to TransactSQL (for example), and some minor modifications to the underlying modules. Then if we want to change the business rules for that data we can change the modules with only minor changes to the app logic.
Contrast this with a mega app written in C which has tons of queries directly in it, a minimum of stored procedures, and a constant stream of bugs because of the morass this has created. The app moves slowly, ponderously, and half the time wrongly.
Anytime I'd be called upon to architect something, I'd be pushing stored procs as much as possible. They're a logical extension of good, modular design.
There are other differences, particularly when it comes to Dimension vs. Precision. Find an SMP capable Precision, for example. And, if you're a corporate customer like I am, the Precision has more profit built in, so I can get free service upgrades, and things like the second proc for free (my dell rep misread my order and quoted me wrong. I then misread the quote and placed the order single CPU. When I pointed out my original email she sent me the processor gratis just to keep me happy. How can she do this? Profit Margin, thats how.)
Obviously not.
Also, English wasn't much spoken when a lot of the major scientific achievments were going on. As far as ground breaking discoveries go, the 1500s through the late 1800s were the boom time. You can only discover gravity once.
Because I used to own it and am too lazy to update my profile on Slashdot. Perhaps someday I'll update it.
Overall though, you're right. This OpenFiler is full of hype and lacking features. They claim to support more protocols than anyone else, which is a gigantic lie. They don't even remotely approach NetApp or Procom, or really even WinSAK based filers.
This is a little out of date, but an excellent book. Particularly for its coverage of using perl to interact with bind config files.
A lot of the concepts are still very relevant, even if the implementation details have changed some. Any competent admin could pick it up, glean the new ideas and implement them in whatever form is comfortable.
A quick example is a financial transaction system using CIPE. With no message sequencing I can replay packets that comprise a sequence of transactions which debit and credit accounts (whether they are accounts I want those transactions on, or just random ones is irrelevant), causing these transactions to repeat an arbitrary number of times. Obviously there'd be some additional safeguards that ought to be there to prevent this, but it is a failing of the protocol to not prevent message replay at a lower level. This is fairly basic protocol design.
You're quite right that overall count doesn't matter quite as much, however I'd not say that not having old patterns is unimportant. Just because it won't run on NT/2k/XP doesn't mean its not important to protect against. I have customers hitting my mail servers who still run truly ancient Windows versions, and they deserve protection too.
I haven't got the experience with Clam to judge their response time, but if you're running a for-profit mail server, you probably have a responsibility to your customers to ensure pattern updates are not only continuing today, but will continue tomorrow. The way to gaurantee that is to pick a vendor with a long term track record, and with some plan in place for tomorrow. Clam may have that, though it was built out of a previous open source AV solution which died, casting a bit of doubt on the whole concept.
What I'd really like to see is an open-source AV engine, and a for pay pattern source that works with that engine. The open source model works great for something like an engine, but not so great for something like pattern updates. One of the hardest parts of generating good pattern files is having a broad enough network of virus trap email accounts out there to catch them early, and get enough copies to get a reliable picture of the virus. Having a large test lab in which you can quickly test new pattern files against thousands of known viruses also helps.
Like I said in my first comment, or at least hope I said, Clam is an excellent choice for home users, but one that needs to be evaluated a lot more closely for commercial applications.
Clam is also not the most resource efficient or scalable AV solution, which when you're running a half million messages a day to almost a hundred thousand users starts to matter.
A real embedded system is the controllers for, say, an automated automobile assembly station. The device builds cars, it just happens to have a brain composed partly of linux/qnx/tron/winCE/PalmOS to do the car building.
Its simple. IP address conservation should be a habit. Always pick the smallest usable subnet. Obviously that needs to take into account growth, but if you think your home network is going to run out of addresses on 192.168.0.0/16 then you should sober up before implementing.
There's also the fact that with some basic scripting and use of some nifty open source tools (and the insanely fast inter-VM "networking") you can maintain one box, and all the rest just fall into line according to the frequency of your cronjobs. If you need to reboot, well, that's darn quick too, and requires zero remote power management (which also raises the MTBF, since power management always seems to fail at inconvenient and/or downright damaging times).
There are enclosures which do this automagically, with redundant controllers and backplanes, along with the ability to use global hot spares, etc so that in the event of a failure the drive is automagically rebuilt. Newer ones even use SMART to detect imminent failure and begin building onto a global hot spare prior to drive failure. Hell, NetApp claims the replacement drive usually shows up in the FedEx truck before the drive has a chance to fail with their SMART monitoring.
Your best bet though is to have two enclosures, each with two channels, each of which is a RAID-5 array. Then hook each enclosure up to two dual channel cards in two boxes, and do an active/passive HA setup, whereby the live box mirrors to the two enclosures (software or hardware, doesn't make much difference), and the standby doesn't even access them (using Fibrechannel you can force this, with SCSI you have to code around it with your HA scripts). The only danger here is in the event of an honest to god total catastrophic failure and both boxes crash. Using homebrew scripts, or the Linux HA project stuff, you're running a serious risk of "split brain" syndrome, where both boxes come up at the same time, and both consider themselves the master and try and fsck both parts of the mirror and fux0r everything.
I warn of this because I experienced it with a Veritas mirrored volume in a VCS cluster. 22 hours on the phone with support, 22 hours with my boss breathing down my neck, 22 hours of customers wondering when they'd be able to get their email because I didn't have the heart to tell them the real question was "if", not "when". Oh yeah, and that was my second day on the job.
The long winded answer, obviously, then is yes. You can do exactly what you described.
Not every piece of hardware that is supported on SCO is supported on Linux, let alone supported well and with the same level of driver features.
For those of us in this position, its a scary thought to think that the community we could always depend on to do their best, people like the GCC community, are being pressured to act in a petty, punitive fashion. GCC dropping SCO support doesn't hurt SCO, it hurts people who might want to flee SCO. If I can't write code to GCC on SCO anymore, I'll need to go find another modern compiler for SCO (good luck, I know) and start writing with that compiler in mind. That means the FSF has achieved the exact opposite of their goal, in that they've forced me into proprietary software, and removed a tool for using even more free software.