"If they can build this Guardian, why don't they do it?" said Shosteck, with the Alliance of Automobile Manufacturers. "It's nice to put something in blueprint form, but we have to build vehicles that go on pavement."
That's really the key paragraph.
Folks, it's easy to snipe at something you know nothing about. Thing is, it's one thing to design something on paper. It's quite another to have something that can actually be built and pass the stringent safety standards of both the US and Europe.
That "efficient engine" may fail to meet acceleration guidelines, or noise guidelines, or emissions guidelines, or who knows what else. And no matter what, since a full car cycle from initial idea through design through testing to actual models in the showroom can easily be five years (and maybe more), this "blueprint" isn't really competing with the cars of today, but the cars of five(+) years from now. In fact, I would not be at all surprised that the cars entering the design phase now in the real automakers are superior to this group of "Concerned Scientists" in every significant way.
There's no conspiracy in the auto industry; they are just selling the cars people want that meet government standards, and a whole lot of other concerns to. (A car is less complicated in most ways then the largest computer programs but they are still not trivial and require a lot more components to be working at ~95%+ of theoretical efficiency to function properly; cars have long since diminishing returns whereas software developers routinely accelerate their routines by factors of 100 or more with an hour's work.)
It's easy to design a car that doesn't have to be driven and score rhetorical points. It's even easier to be a bystander that knows nothing about car design and assume that this new design is being "suppressed". Making cars that meet all of the requirements of the government AND the market AND making a profit, now that's hard.
Speaking broadly, things that happen past the age of reproduction don't affect evolution or natural selection much, as the owner of the genes has either bred or not by then.
Some exceptions exist for organisms which form societies, as ours do, but even then, those are the exceptions, not the rule. I think "hair loss" is perfectly adequately explained as a mutation that got into the gene pool (and remember that humanity has gone through at least one very small bottleneck and possibly more then one; you can look that up elsewhere) and just happened to spread along with other genes. No "explanation" is really necessary, IMHO.
That's just my opinion... but when it comes to these sorts of issues, it's hard to get anything better then that;-) One can hardly conduct "experiments" on this sort of thing.
The appearence of color is not due to the reflection of one and only one color.
No shit. That does not change the fact that chlorophyll does indeed reflect green. Take a logic class if you still don't understand why that's the case.
Dear God, you were serious. I hope I never have to use any of your programs! I remember the days of fixed memory records limitations being exposed to the actual users. I do not miss them in the slightest.
That's one allocation. And you would do an allocation per line? Boy that's silly. In this scheme, there is no overflow.
Uh, mmap is great, but it means you're dealing directly with dynamic record sizes, since you can make no guarentees about how long the records are in the file. In fact mmap is exactly the right answer and exactly what you should do, but in a static allocation world, you can't.
If the file is too big or over a threshold, probably should require some extra priviledges to sort.
"I'm too stupid as a programmer to handle dynamic records, so I'm going to ask the user to jump through hoops to do things with large files." Yes, shift the burden to the user, THAT will make them love you. Damn it, the users are here to service the programmers, not the other way around!
swap file argument red herring Most applications have no control over when the O/S swaps out a physical page. I will tell you that if you are doing stuff with the VM, you are going to know exactly at least the locality of things getting swapped out.
Sorry, but this comment makes it quite clear you didn't understand what I was saying. At all.
You seemed to have switched from "fixed record sizes are easier and therefore safer", as in
The whole reason that security issues have proliferated is our stubborn insistence on allowing for variable input. If all input and systems had hard wired capacities, then, there could be no denial of service attacks as program behavior would be bounded.
(which incidentally, as I said, is still wrong since you still have to check if you're overflowing the buffer, be it static or dynamic!)
to, rather suddenly, "dynamic allocation is expensive" as in
If, on the other hand, I do a clever thing and get an O( 1 ) serach, then, as I would if my next free block were a simple pointer addition, then, I pay little CPU tax at all.
where your first message has nothing about CPU costs at all.
But on that topic... you're still wrong. If you're wastefully allocating space in your static buffers for real processing tasks like "string processing" your program will get hosed because it will go to swap long before a program that only allocates the necessary space will. Your (proposed) style of programming is only appropriate on processors so small we stick them in digital watches and for things that never have variable input, like sensors. You couldn't even write a web server with your philosophy, at least not one that would be thorougly trounced in any real performance test.
Eh, why do I bother; you're clearly pretty clueless about computers anyhow, as your persistent and rather odd belief that you don't have to check static buffers when dealing with variable input (and the variable input isn't going away, buddy) shows. That DOS crack on the last line was oddly pointless too; yeah, I suppose your "I just shut the program off if the input is too large" or "the user should use a DIFFERENT program to work with the input that's too large" does avoid DOS attacks; programs that don't do anything useful worth mentioning can't be DOSed, but who cares?
"What, a megabyte-plus-one of data? Fuck you, user, that's too large. I'm crashing now!"or "What, a megabyte-plus-one of data? Fuck you, user, you should know to use PROCESS_MEGABYTE_THROUGH_TWO_MEGABYTES, not PROCESS_UP_TO_MEGABYTE. Duh!"
They aren't. "Filtered" means the packet sent to that port simply disappeared, without even a error packet coming back to indicate the failure. In other words, indistinguishable from "There is no machine at all receiving the packet". Here's how to use nmap, see the third paragraph.
The server is only running smtp and http, and theoretically it could be running services on the tens of thousands of other ports you didn't scan, but it almost certainly isn't.
Those filtered ports are why the nmap scan took 24.611 seconds; system without filtered ports will go faster then that under normal circumstances.
By making a typo, you supposedly agree that if their site overflows a buffer in your browser and wipes your HD, they are not liable.
This is so unlikely to stick I can't imagine why Verisign bothered, except that a lawyer in the organization probably felt the need to justify his (or her) paycheck.
EULAs are already quite legally questionable; to claim a TOS is binding when the user completely and utterly accidentally visited your site would not stand up in court. (Unless you really and truly believe that courts truly decide solely on the basis of cash, in which case I suggest you should wake up and smell the coffee; I won't say it's not an influence but it's not 100% and you're not being "sophisticated" for thinking so, you're being naive.) Not to mention one could claim that Verisign is degrading our Internet connection, and for a contract to be binding we're supposed to receive something of value. (Not to mention we've received the putatively valuable thing before any conceivable way to see the contract.)
Basically, take all the legal questions surrounding EULAs and add several more major faults, and you've got these TOS. TOS on a conventional website are also kind of tricky when you just implicitly "agree" to them without even clicking through something first; that's another case of "agreeing to something I wasn't even aware existed"... I'm not sure how much less consent I can possibly give to these sorts of things, short of companies starting to simply assert that I am bound to a contract. (Note: If you're thinking of going into fraud as a way of life, there may be something to that concept, if you're clever.) I'm not aware of any cases regarding those TOS going to court either and I'm pretty sure I would have heard about it (probably even on Slashdot).
They might as well try to charge us something or claim our firstborns while they are at it.
Actually, to be fair, I've been to four or five movies this year, and I was listening for this and other cliches. I only heard one in the 20 or 30 previews, and it was done self-referentially. (Don't remember what for.)
Granted, that's not a whole lot of movies and they were all in the action genre (the only genre I care to see in theatres because the sound and video slaughter anything I can muster in my apartment) so it's far from a statistically rigorous sample, but I think they're actually not using the cliches anymore. It's only a matter of time before new ones develop, but let's give credit where credit's due.
If there is anything we've learned over the past 50 years, it's that programmers aren't Gods, and can not predict all the uses their programs will be put to.
Programming with dynamic structures in C may be challenging, but the alternative is to create a program that is much, much, much, much less useful. Who going to use a "grep" that limits at 1024 chars per line nowadays? Who's going to use a "sort" that allocates 64KB per line, making even relatively small files overload the system memory and flop out to swap?
This sort of suggestion sounds all wonderful and stuff until you remember (or learn, if you never did before) that in the general case, static buffers means either extreme memory wastage or overflowing the buffers anyhow, and possibly both. Plus static buffers gets you nothing in C, because static or dynamic you still need to check whether you're overflowing it!
Folks, I'm pretty sure this was a Troll, not an Insightful post, and quite a lot of you got taken. You think this is such a wonderful programming style, why don't you try using it for a real program. You'll see why it's useless in short order. If you're lucky you'll still have a job after that little experiment.
(And finally, dynamic programming doesn't have to be hard. I write in Perl and Python and the last time I worried about a buffer's size explicitly was when we were concerned about how much disk it would take to serialize a data structure and keep it around. Use a real language and this concern goes away. Study up on optimization techniques and you'll see that you don't necessarily even have to pay a huge processor penalty, those are just artefacts of relatively naive implementations. (Note "naive" here does not imply "bad", it's just a descriptive adverb.))
Hey braintrust, from this message's great-grandparent: "(provided by Google)".
"Lazy" right back atcha, squared; you can't even be bothered to read the comments completely when you're <fingerMotion type="exaggerated quotes" strength="8">correcting</fingerMotion> someone else!
One is a stacked silicon junction, which could have an efficiency greater than the present ones because successive layers presumably absorb light not picked up by the top layer.
The problem with current designs is not that it does not use "100%" of the light per se, it's that it can only use certain wavelengths. If you can only turn "green" into electricity, then it doesn't matter how many you stack on each other, the first gets the green (and fruitlessly absorbs other things too), and the next gets nothing it can use.
"Light" is not a single thing, it's a whole lot of frequencies, all at once.
(Note that plants are the worst at using "green", chlorophyll reflects it. That's why plants are green. Shine a blue and a green light on a plant with the same intensity (in watts) and the two plants will do vastly differently.)
Are you 100% certain that's the correct "Thomas Rocca"? I'm not the only one with my name in my city, and while "Rocca" may not be terribly common, "Thomas" certainly is.
Would it surprise you too much if the real Thomas Rocca had an unlisted number, and this is just some poor guy who happens to share his name with a scumbag?
Please don't call this guy unless you can be more sure you're not hurting an innocent.
Yeah, patents suck and all, but there's one thing I'm not understanding here.
If Microsoft is forced to pay off Eolas, doesn't that mean they've paid for the patent? Does anyone seriously think that Eolas won't license the patent to Microsoft, or even be forced to by the judge? Why is the assumption that Microsoft will automatically be forced to remove the technology when they just paid half a billion dollars for it?
I admit I'd like to see Microsoft forced to remove it to highlight the fact that patent criticisms like mine are grounded in solid reality and not abstract fantasy, but I just can't see that happening this time. Instead, Microsoft will probably just pony up, because unless they really realize this is going to keep happening, over and over again, they probably still think the patent system is still a net gain for them, allowing them to use the system like this against certain pesky start-ups that may refuse to be bought out.
Ha ha, that's funny... but not for the reason you think it is. Microsoft's market capitalization is $300 billion, so he'd be short by nearly a factor of five. You can't even get a controlling interest for $65 billion.
Of course, I should also add that both numbers would be a lot lower if the Slashcode theme remotely resembled web standards instead of horrendous amounts of nested tables and "spacer" graphics, but that's getting off-topic.....
Actually, try downloading your page, copying it, gzipping the original, cleaning up the copy to your specs, gzipping that, and comparing the two file sizes. While you may kill a lot of text in the uncompressed version, I would strongly suspect you'll find that the gzip'ped version saved much less then you think.
Those "spacer gifs" that take up perhaps 100bytes apiece in the original file (perhaps a bit generous) will compress away down to very little (if there are several near each other, they may literally compress down to a handful of bits after the first one), whereas the story text compresses much less well.
If you're compressing things, XML, CSS, and a lot of other things that look awfully redundent in plain-text are suddenly downright bandwidth-efficient technologies, being dwarfed in their compressed representations by the plain-text payloads. This is one of the reasons that fundamentally XML is so cool; you get human readability, but for the very small effort of invoking gzip or similar compresion technology, you also get something that is very nearly as bandwidth-efficient as possible, because compression technologies dynamically determine the best binary encodings for such messages (including their plain-text payloads), whereas supposed "efficient" binary protocols may actually waste a lot of space. (Compressing the both of them may equalize them, but the binary file, perversely, will still be "harder" to compress, even with nearly the same information in both files.)
How compression behaves is not necessarily intuitive.
One of my two "main" programming projects at the moment is a Rogue-like that tries to do for plot what Rogue did for level generation. I put "main" in quotes because it has since been overshadowed by the other main project I'm doing, but I still hope to get back to it someday.
For anybody else who would like to take this up, since you could probably finish at least a "0.1" release before I turn back to this project personally, I would point out what is probably "the way" to do that sort of thing. The fundamental problem with modern roguelikes is they are too low-level, where "the dungeon" is an array describing what is there, and "the engine" just manipulates this. Thus, "the engine" is only capable of generating really low-level events, like "X killed Y".
To get a "plot" in place, you need to generate a much higher-level representation of the world to start with. You need to start with what "groups" are in place (cities, towns, nations), maybe run through a routine that does high-level generation of the map (placing these groups in cities, etc.), then iterate down to the next level where the groups are given relationships and placed in actual buildings, then iterate on the landscape again, then build actual people in the context of the groups, then build the place for the people, etc. When you're done, you'll have not only a map like a current Roguelike does, but also an engine with a much higher-level understanding of what the map actually has on it, allowing quests like "Get X out of the evil henchmen's building and return them to Y", etc.
(Alternatively, you can try to "grow" the land, starting by placing down the general landscape, then adding settlements and using some basic economic rules to govern how they grow and interact, then try to create the "game" at the end.)
Obviously in a Slashdot post I can't explain too much, but IMHO at least in the Open Source efforts I've seen (and even many commercial ones) this is the fundamental mistake I've seen made at the architecture level that prevents this stuff from working. It probably seems obvious after you've thought about it for a while but it apparently isn't. From here you can probably fill it out too. (If not, perhaps you should be thinking of something else to do.;-) )
One warning: You're going to need (or really wish you had) some actual Computer Science to pull this off well, specifically the study of expanding unrestricted grammars into final statements, which is essentially what this is, especially when it comes time to add links between the entities (for instance, antagonism between a "legitimate government" of a town and the underground theive's guild). It's not easy, but IMNSHO it's the only way likely to work.
I'm quite certain this is possible and I have a design half-sketched out, I just haven't had time to implement it until my other project becomes at least self-sustaining.
If you keep good logs then the cost of making sure he didn't steal or damage sensitive data isn't all that difficult (provided, of course, he didn't steal or damage sensitive data).
I disagree. One of the problem is that when a hacker attacks, you can't necessarily trust the logs. In fact there's a lot of people of the opinion (and I'm one of them) that unless you really know exactly which vulnerability was exploited and how it was exploited (like a common worm comes in that doesn't install a shell and there's no evidence that there was any other person actively involved in the hack), the only proper thing to do is completely re-install the system from either known-good backups (and labelling backups "known good" is itself an interesting challenge), or even from the original CDs.
Things like "tripwire" are just that... tripwires. They really shouldn't be used to help repair the system because once the system is compromised you can no longer trust the output.
For a business-critical machine, and well-paid admins (which you should have!), and counting downtime, $25,000 is entirely reasonable.
Spending money to fix the vulnerability Adrian exploited cannot really be considered a loss (it has an ROI, in fact).
Since fixing a vulnerability is typically a matter of applying a patch, odds are it does not account for more then $100 or $200 of the damage if it was computed rationally. Evaluation, analysis (which even if you re-install from scratch MUST be done, to see if any customer or private data was compromised), re-install, and lost business swamps that expense. Trying to talk the damage value of this down isn't really useful since it's such a small part of the value, in all likelihood.
$25,000 is quite reasonable.
Since he would not have otherwise paid $300,000 for the service, he didn't really cost them that money.
Yes, this is most likely absurdly inflated.
1 for 2 is actually a significant improvement for our system, and this is a good sign, IMHO.
I think you may have missed that "How many games does a man have to make before he gets your respect?" was a quote from an anonymous coward; my contribution was only the reference.
For a while now, I've noticed that "the far future" has been coming closer and closer to the present.
H. G. Wells sent his protagonist in "The Time Machine", if memory serves me, billions of years into the future. (If not that, then certainly many millions.) I like "Golden Age" science fiction (which I mean, loosely, late 1930s to the early 1960s), and if anybody was timetraveling back from the future, it would be many tens or hundreds of thousands of years hence. A careful reading of Dune shows it to be tens of thousands of years in the future, with thousand of years between God Emperor of Dune and the next two books (which is basically one book cut in two).
The farther ahead you come, the closer the horizon gets, with rare exceptions. Much of this can probably attributed to the general recognition of the Singularity arguments; even if you don't agree with their logical conclusion, change is accelerating.
Most of those exceptions I've seen tend to involve some form of ultimate limit of technology; "A Fire Upon The Deep" has the "Zones of Thought", where where you are in the galaxy controls the ultimate height of your technology. (And we're in the "Slow Zone", where FTL is fundamentally impossible.) It takes place an indefinate period in the future, but probably many thousands to tens of thousands of years in the future.
Considering sci-fi as "future literature" (a definition I do not generally hold to and only adopt for the purposes of this post), it has become extremely difficult to look even 50 years into the future and see anything like what we would call "humanity" looking back at you. A few authors are still gamely trying, and I enjoy them, but I wonder if part of the reason we are retreating into fantasy is that we've despaired of predicting the future; if your book takes two years to write (reasonable for a truly good effort), your real world can shift right out from underneath you! ("Oh yeah, high temperature superconductors, they ARE possible." "Oh, hey, the universe IS expanding at an accelerating pace; there goes my 'Big Crunch' story! Shit!" I think it was Asimov who placed a story on a Mercury that was tidally locked to the sun as a critical part of the story, and between printing and distribution, it was revealed that Mercury's day is 2/3 of a year (or something like that, not looking it up). Oops! That's gotten more common.)
I think "the far future" has simply contracted to be about 10 years from now. I don't know about you, but I'm about to turn 25, and while on the one hand I've noticed a week going by is certainly going faster then when I was 10, I'm hearing followups to stories from 3 months ago and saying to myself, "My gosh, that was only 3 months ago? So much has happened since then! That feels like two or three years ago." The 2004 Presidential campaign alone seems to have generated more news to me then the 1996 campaign did by its conclusion, and we're not even really close to the end of 2003! (Think the "Dean" story.)
I'd pity later historians of this era, but it's only getting worse; historians may someday retreat into studying the relative calm of the 20th century, already almost as exciting as the entire rest of human history combined.
Is it any wonder so few authors care to dare these waters, and only do so if they can reasonably limit the turbulence somehow (Zones of Thought, wars or other events holding back progress for a significant period of time.)? At least Fantasy doesn't change before you can publish the book!
Do I admire people who take the initiative and create challenge in their games by trying ridiculous things (such as the no-materia, all-initial-weapon completion of Final Fantasy VII)? Without a doubt. Just because the superweapon is coded into the game doesn't mean you have to use it.
Oh, absolutely! I'm on my second "clean-up" game of Tactics Ogre and when that's done, barring FFTA ownership (which due to $$$ may not be immediate even if I do buy it eventually), I plan on trying the "Single Character Challenge", where you try to defeat the game using only the main character. (Apparently it is possible; there are some points in the game where you must split your forces and fight two battles "at once", so the game writers must have explicitly handled that case; thanks!) Considering Tactics Ogre has 8-char parties (for those who don't know that), that's quite a challenge.
(it took me 16 months to finally finish Tactics Ogre: KOL)
Well, it didn't take me anywhere near "16 months", but that's not the greatest measure. For me, I measured by the fact I only lost two battles in my first pass through. That's not very good, really; I expect better then that. This second time through the battles are almost perfunctory.
BTW, Hint: It's all about the heal, the only thing in these games (tactics RPGs and conventional RPGs) that have no real-world counterparts. (We can deal the damage out in the real world as much as you'd like; waving a magic wand and bringing a person from 1HP to 11,342HP in a single turn is a bit harder.) If you're really having trouble in Tactics Ogre for instance, stacking three healers on your team (including Knights with the heal spell) will win nearly any battle, though not necessarily quickly, as long as you keep your healers alive.
Ever noticed your enemies almost NEVER have heal, and even more rarely have "full heal"? (Yes, I know, it's been done, but it is rare; there's this one boss in Skies of Arcadia in the middle that has Full Heal; low probability but quite annoying when it fires when you've got one turn to go!) That's because they'd often be nearly unbeatable if they did; they'd CERTAINLY be unbeatable if they used it intelligently. Healing is the key.
Slashdot Mirror
That's really the key paragraph.
Folks, it's easy to snipe at something you know nothing about. Thing is, it's one thing to design something on paper. It's quite another to have something that can actually be built and pass the stringent safety standards of both the US and Europe.
That "efficient engine" may fail to meet acceleration guidelines, or noise guidelines, or emissions guidelines, or who knows what else. And no matter what, since a full car cycle from initial idea through design through testing to actual models in the showroom can easily be five years (and maybe more), this "blueprint" isn't really competing with the cars of today, but the cars of five(+) years from now. In fact, I would not be at all surprised that the cars entering the design phase now in the real automakers are superior to this group of "Concerned Scientists" in every significant way.
There's no conspiracy in the auto industry; they are just selling the cars people want that meet government standards, and a whole lot of other concerns to. (A car is less complicated in most ways then the largest computer programs but they are still not trivial and require a lot more components to be working at ~95%+ of theoretical efficiency to function properly; cars have long since diminishing returns whereas software developers routinely accelerate their routines by factors of 100 or more with an hour's work.)
It's easy to design a car that doesn't have to be driven and score rhetorical points. It's even easier to be a bystander that knows nothing about car design and assume that this new design is being "suppressed". Making cars that meet all of the requirements of the government AND the market AND making a profit, now that's hard.
Speaking broadly, things that happen past the age of reproduction don't affect evolution or natural selection much, as the owner of the genes has either bred or not by then.
;-) One can hardly conduct "experiments" on this sort of thing.
Some exceptions exist for organisms which form societies, as ours do, but even then, those are the exceptions, not the rule. I think "hair loss" is perfectly adequately explained as a mutation that got into the gene pool (and remember that humanity has gone through at least one very small bottleneck and possibly more then one; you can look that up elsewhere) and just happened to spread along with other genes. No "explanation" is really necessary, IMHO.
That's just my opinion... but when it comes to these sorts of issues, it's hard to get anything better then that
The appearence of color is not due to the reflection of one and only one color.
No shit. That does not change the fact that chlorophyll does indeed reflect green. Take a logic class if you still don't understand why that's the case.
That's one allocation. And you would do an allocation per line? Boy that's silly. In this scheme, there is no overflow.
Uh, mmap is great, but it means you're dealing directly with dynamic record sizes, since you can make no guarentees about how long the records are in the file. In fact mmap is exactly the right answer and exactly what you should do, but in a static allocation world, you can't.
If the file is too big or over a threshold, probably should require some extra priviledges to sort.
"I'm too stupid as a programmer to handle dynamic records, so I'm going to ask the user to jump through hoops to do things with large files." Yes, shift the burden to the user, THAT will make them love you. Damn it, the users are here to service the programmers, not the other way around!
swap file argument red herring
Most applications have no control over when the O/S swaps out a physical page. I will tell you that if you are doing stuff with the VM, you are going to know exactly at least the locality of things getting swapped out.
Sorry, but this comment makes it quite clear you didn't understand what I was saying. At all.
You seemed to have switched from "fixed record sizes are easier and therefore safer", as in(which incidentally, as I said, is still wrong since you still have to check if you're overflowing the buffer, be it static or dynamic!)
to, rather suddenly, "dynamic allocation is expensive" as in
where your first message has nothing about CPU costs at all.
But on that topic... you're still wrong. If you're wastefully allocating space in your static buffers for real processing tasks like "string processing" your program will get hosed because it will go to swap long before a program that only allocates the necessary space will. Your (proposed) style of programming is only appropriate on processors so small we stick them in digital watches and for things that never have variable input, like sensors. You couldn't even write a web server with your philosophy, at least not one that would be thorougly trounced in any real performance test.
Eh, why do I bother; you're clearly pretty clueless about computers anyhow, as your persistent and rather odd belief that you don't have to check static buffers when dealing with variable input (and the variable input isn't going away, buddy) shows. That DOS crack on the last line was oddly pointless too; yeah, I suppose your "I just shut the program off if the input is too large" or "the user should use a DIFFERENT program to work with the input that's too large" does avoid DOS attacks; programs that don't do anything useful worth mentioning can't be DOSed, but who cares?
"What, a megabyte-plus-one of data? Fuck you, user, that's too large. I'm crashing now!"or "What, a megabyte-plus-one of data? Fuck you, user, you should know to use PROCESS_MEGABYTE_THROUGH_TWO_MEGABYTES, not PROCESS_UP_TO_MEGABYTE. Duh!"
They aren't. "Filtered" means the packet sent to that port simply disappeared, without even a error packet coming back to indicate the failure. In other words, indistinguishable from "There is no machine at all receiving the packet". Here's how to use nmap, see the third paragraph.
The server is only running smtp and http, and theoretically it could be running services on the tens of thousands of other ports you didn't scan, but it almost certainly isn't.
Those filtered ports are why the nmap scan took 24.611 seconds; system without filtered ports will go faster then that under normal circumstances.
By making a typo, you supposedly agree that if their site overflows a buffer in your browser and wipes your HD, they are not liable.
This is so unlikely to stick I can't imagine why Verisign bothered, except that a lawyer in the organization probably felt the need to justify his (or her) paycheck.
EULAs are already quite legally questionable; to claim a TOS is binding when the user completely and utterly accidentally visited your site would not stand up in court. (Unless you really and truly believe that courts truly decide solely on the basis of cash, in which case I suggest you should wake up and smell the coffee; I won't say it's not an influence but it's not 100% and you're not being "sophisticated" for thinking so, you're being naive.) Not to mention one could claim that Verisign is degrading our Internet connection, and for a contract to be binding we're supposed to receive something of value. (Not to mention we've received the putatively valuable thing before any conceivable way to see the contract.)
Basically, take all the legal questions surrounding EULAs and add several more major faults, and you've got these TOS. TOS on a conventional website are also kind of tricky when you just implicitly "agree" to them without even clicking through something first; that's another case of "agreeing to something I wasn't even aware existed"... I'm not sure how much less consent I can possibly give to these sorts of things, short of companies starting to simply assert that I am bound to a contract. (Note: If you're thinking of going into fraud as a way of life, there may be something to that concept, if you're clever.) I'm not aware of any cases regarding those TOS going to court either and I'm pretty sure I would have heard about it (probably even on Slashdot).
They might as well try to charge us something or claim our firstborns while they are at it.
In a world... where a man...
Actually, to be fair, I've been to four or five movies this year, and I was listening for this and other cliches. I only heard one in the 20 or 30 previews, and it was done self-referentially. (Don't remember what for.)
Granted, that's not a whole lot of movies and they were all in the action genre (the only genre I care to see in theatres because the sound and video slaughter anything I can muster in my apartment) so it's far from a statistically rigorous sample, but I think they're actually not using the cliches anymore. It's only a matter of time before new ones develop, but let's give credit where credit's due.
Grammar Nazi is a moron (definition #1, of all things...).
(Note this is a reply to an Anonymous Coward which is probably being filtered out for you; in this case, justly so.)
If there is anything we've learned over the past 50 years, it's that programmers aren't Gods, and can not predict all the uses their programs will be put to.
Programming with dynamic structures in C may be challenging, but the alternative is to create a program that is much, much, much, much less useful. Who going to use a "grep" that limits at 1024 chars per line nowadays? Who's going to use a "sort" that allocates 64KB per line, making even relatively small files overload the system memory and flop out to swap?
This sort of suggestion sounds all wonderful and stuff until you remember (or learn, if you never did before) that in the general case, static buffers means either extreme memory wastage or overflowing the buffers anyhow, and possibly both. Plus static buffers gets you nothing in C, because static or dynamic you still need to check whether you're overflowing it!
Folks, I'm pretty sure this was a Troll, not an Insightful post, and quite a lot of you got taken. You think this is such a wonderful programming style, why don't you try using it for a real program. You'll see why it's useless in short order. If you're lucky you'll still have a job after that little experiment.
(And finally, dynamic programming doesn't have to be hard. I write in Perl and Python and the last time I worried about a buffer's size explicitly was when we were concerned about how much disk it would take to serialize a data structure and keep it around. Use a real language and this concern goes away. Study up on optimization techniques and you'll see that you don't necessarily even have to pay a huge processor penalty, those are just artefacts of relatively naive implementations. (Note "naive" here does not imply "bad", it's just a descriptive adverb.))
Oh, and please mod parent back down, mm'kay?
Hey braintrust, from this message's great-grandparent: "(provided by Google)".
"Lazy" right back atcha, squared; you can't even be bothered to read the comments completely when you're <fingerMotion type="exaggerated quotes" strength="8">correcting</fingerMotion> someone else!
One is a stacked silicon junction, which could have an efficiency greater than the present ones because successive layers presumably absorb light not picked up by the top layer.
The problem with current designs is not that it does not use "100%" of the light per se, it's that it can only use certain wavelengths. If you can only turn "green" into electricity, then it doesn't matter how many you stack on each other, the first gets the green (and fruitlessly absorbs other things too), and the next gets nothing it can use.
"Light" is not a single thing, it's a whole lot of frequencies, all at once.
(Note that plants are the worst at using "green", chlorophyll reflects it. That's why plants are green. Shine a blue and a green light on a plant with the same intensity (in watts) and the two plants will do vastly differently.)
Are you 100% certain that's the correct "Thomas Rocca"? I'm not the only one with my name in my city, and while "Rocca" may not be terribly common, "Thomas" certainly is.
Would it surprise you too much if the real Thomas Rocca had an unlisted number, and this is just some poor guy who happens to share his name with a scumbag?
Please don't call this guy unless you can be more sure you're not hurting an innocent.
Yeah, patents suck and all, but there's one thing I'm not understanding here.
If Microsoft is forced to pay off Eolas, doesn't that mean they've paid for the patent? Does anyone seriously think that Eolas won't license the patent to Microsoft, or even be forced to by the judge? Why is the assumption that Microsoft will automatically be forced to remove the technology when they just paid half a billion dollars for it?
I admit I'd like to see Microsoft forced to remove it to highlight the fact that patent criticisms like mine are grounded in solid reality and not abstract fantasy, but I just can't see that happening this time. Instead, Microsoft will probably just pony up, because unless they really realize this is going to keep happening, over and over again, they probably still think the patent system is still a net gain for them, allowing them to use the system like this against certain pesky start-ups that may refuse to be bought out.
Ha ha, that's funny... but not for the reason you think it is. Microsoft's market capitalization is $300 billion, so he'd be short by nearly a factor of five. You can't even get a controlling interest for $65 billion.
Microsoft is big, dude!
Apparently you didn't keep it simpel enough. YOur message has capatilization wierd. and other starnge shit. MY borswer must be messing your messge.
oh on its cathcing! Dman YOu! i use Gen2 and IT'll take me days 2 recompil everythang to fixc my mzolille!!!!1!
Have you submitted one?
Of course, I should also add that both numbers would be a lot lower if the Slashcode theme remotely resembled web standards instead of horrendous amounts of nested tables and "spacer" graphics, but that's getting off-topic.....
Actually, try downloading your page, copying it, gzipping the original, cleaning up the copy to your specs, gzipping that, and comparing the two file sizes. While you may kill a lot of text in the uncompressed version, I would strongly suspect you'll find that the gzip'ped version saved much less then you think.
Those "spacer gifs" that take up perhaps 100bytes apiece in the original file (perhaps a bit generous) will compress away down to very little (if there are several near each other, they may literally compress down to a handful of bits after the first one), whereas the story text compresses much less well.
If you're compressing things, XML, CSS, and a lot of other things that look awfully redundent in plain-text are suddenly downright bandwidth-efficient technologies, being dwarfed in their compressed representations by the plain-text payloads. This is one of the reasons that fundamentally XML is so cool; you get human readability, but for the very small effort of invoking gzip or similar compresion technology, you also get something that is very nearly as bandwidth-efficient as possible, because compression technologies dynamically determine the best binary encodings for such messages (including their plain-text payloads), whereas supposed "efficient" binary protocols may actually waste a lot of space. (Compressing the both of them may equalize them, but the binary file, perversely, will still be "harder" to compress, even with nearly the same information in both files.)
How compression behaves is not necessarily intuitive.
One of my two "main" programming projects at the moment is a Rogue-like that tries to do for plot what Rogue did for level generation. I put "main" in quotes because it has since been overshadowed by the other main project I'm doing, but I still hope to get back to it someday.
;-) )
For anybody else who would like to take this up, since you could probably finish at least a "0.1" release before I turn back to this project personally, I would point out what is probably "the way" to do that sort of thing. The fundamental problem with modern roguelikes is they are too low-level, where "the dungeon" is an array describing what is there, and "the engine" just manipulates this. Thus, "the engine" is only capable of generating really low-level events, like "X killed Y".
To get a "plot" in place, you need to generate a much higher-level representation of the world to start with. You need to start with what "groups" are in place (cities, towns, nations), maybe run through a routine that does high-level generation of the map (placing these groups in cities, etc.), then iterate down to the next level where the groups are given relationships and placed in actual buildings, then iterate on the landscape again, then build actual people in the context of the groups, then build the place for the people, etc. When you're done, you'll have not only a map like a current Roguelike does, but also an engine with a much higher-level understanding of what the map actually has on it, allowing quests like "Get X out of the evil henchmen's building and return them to Y", etc.
(Alternatively, you can try to "grow" the land, starting by placing down the general landscape, then adding settlements and using some basic economic rules to govern how they grow and interact, then try to create the "game" at the end.)
Obviously in a Slashdot post I can't explain too much, but IMHO at least in the Open Source efforts I've seen (and even many commercial ones) this is the fundamental mistake I've seen made at the architecture level that prevents this stuff from working. It probably seems obvious after you've thought about it for a while but it apparently isn't. From here you can probably fill it out too. (If not, perhaps you should be thinking of something else to do.
One warning: You're going to need (or really wish you had) some actual Computer Science to pull this off well, specifically the study of expanding unrestricted grammars into final statements, which is essentially what this is, especially when it comes time to add links between the entities (for instance, antagonism between a "legitimate government" of a town and the underground theive's guild). It's not easy, but IMNSHO it's the only way likely to work.
I'm quite certain this is possible and I have a design half-sketched out, I just haven't had time to implement it until my other project becomes at least self-sustaining.
If you keep good logs then the cost of making sure he didn't steal or damage sensitive data isn't all that difficult (provided, of course, he didn't steal or damage sensitive data).
I disagree. One of the problem is that when a hacker attacks, you can't necessarily trust the logs. In fact there's a lot of people of the opinion (and I'm one of them) that unless you really know exactly which vulnerability was exploited and how it was exploited (like a common worm comes in that doesn't install a shell and there's no evidence that there was any other person actively involved in the hack), the only proper thing to do is completely re-install the system from either known-good backups (and labelling backups "known good" is itself an interesting challenge), or even from the original CDs.
Things like "tripwire" are just that... tripwires. They really shouldn't be used to help repair the system because once the system is compromised you can no longer trust the output.
For a business-critical machine, and well-paid admins (which you should have!), and counting downtime, $25,000 is entirely reasonable.
Spending money to fix the vulnerability Adrian exploited cannot really be considered a loss (it has an ROI, in fact).
Since fixing a vulnerability is typically a matter of applying a patch, odds are it does not account for more then $100 or $200 of the damage if it was computed rationally. Evaluation, analysis (which even if you re-install from scratch MUST be done, to see if any customer or private data was compromised), re-install, and lost business swamps that expense. Trying to talk the damage value of this down isn't really useful since it's such a small part of the value, in all likelihood.
$25,000 is quite reasonable.
Since he would not have otherwise paid $300,000 for the service, he didn't really cost them that money.
Yes, this is most likely absurdly inflated.
1 for 2 is actually a significant improvement for our system, and this is a good sign, IMHO.
I think you may have missed that "How many games does a man have to make before he gets your respect?" was a quote from an anonymous coward; my contribution was only the reference.
How many times does someone have to revolutionize gaming before they get your respect?
42!
Nah... that's not it... [walks away muttering]
My old game boy was white. White is for purity, chastity....oh crap.
Your Game Boy got around? Wow, your Game Boy outscored quite a few people reading this comment.
Tell me, was he (or she...) a "playa'"?
"Insert tab A into slot B" indeed.
OK, I'll stop.
For a while now, I've noticed that "the far future" has been coming closer and closer to the present.
H. G. Wells sent his protagonist in "The Time Machine", if memory serves me, billions of years into the future. (If not that, then certainly many millions.) I like "Golden Age" science fiction (which I mean, loosely, late 1930s to the early 1960s), and if anybody was timetraveling back from the future, it would be many tens or hundreds of thousands of years hence. A careful reading of Dune shows it to be tens of thousands of years in the future, with thousand of years between God Emperor of Dune and the next two books (which is basically one book cut in two).
The farther ahead you come, the closer the horizon gets, with rare exceptions. Much of this can probably attributed to the general recognition of the Singularity arguments; even if you don't agree with their logical conclusion, change is accelerating.
Most of those exceptions I've seen tend to involve some form of ultimate limit of technology; "A Fire Upon The Deep" has the "Zones of Thought", where where you are in the galaxy controls the ultimate height of your technology. (And we're in the "Slow Zone", where FTL is fundamentally impossible.) It takes place an indefinate period in the future, but probably many thousands to tens of thousands of years in the future.
Considering sci-fi as "future literature" (a definition I do not generally hold to and only adopt for the purposes of this post), it has become extremely difficult to look even 50 years into the future and see anything like what we would call "humanity" looking back at you. A few authors are still gamely trying, and I enjoy them, but I wonder if part of the reason we are retreating into fantasy is that we've despaired of predicting the future; if your book takes two years to write (reasonable for a truly good effort), your real world can shift right out from underneath you! ("Oh yeah, high temperature superconductors, they ARE possible." "Oh, hey, the universe IS expanding at an accelerating pace; there goes my 'Big Crunch' story! Shit!" I think it was Asimov who placed a story on a Mercury that was tidally locked to the sun as a critical part of the story, and between printing and distribution, it was revealed that Mercury's day is 2/3 of a year (or something like that, not looking it up). Oops! That's gotten more common.)
I think "the far future" has simply contracted to be about 10 years from now. I don't know about you, but I'm about to turn 25, and while on the one hand I've noticed a week going by is certainly going faster then when I was 10, I'm hearing followups to stories from 3 months ago and saying to myself, "My gosh, that was only 3 months ago? So much has happened since then! That feels like two or three years ago." The 2004 Presidential campaign alone seems to have generated more news to me then the 1996 campaign did by its conclusion, and we're not even really close to the end of 2003! (Think the "Dean" story.)
I'd pity later historians of this era, but it's only getting worse; historians may someday retreat into studying the relative calm of the 20th century, already almost as exciting as the entire rest of human history combined.
Is it any wonder so few authors care to dare these waters, and only do so if they can reasonably limit the turbulence somehow (Zones of Thought, wars or other events holding back progress for a significant period of time.)? At least Fantasy doesn't change before you can publish the book!
Do I admire people who take the initiative and create challenge in their games by trying ridiculous things (such as the no-materia, all-initial-weapon completion of Final Fantasy VII)? Without a doubt. Just because the superweapon is coded into the game doesn't mean you have to use it.
Oh, absolutely! I'm on my second "clean-up" game of Tactics Ogre and when that's done, barring FFTA ownership (which due to $$$ may not be immediate even if I do buy it eventually), I plan on trying the "Single Character Challenge", where you try to defeat the game using only the main character. (Apparently it is possible; there are some points in the game where you must split your forces and fight two battles "at once", so the game writers must have explicitly handled that case; thanks!) Considering Tactics Ogre has 8-char parties (for those who don't know that), that's quite a challenge.
(it took me 16 months to finally finish Tactics Ogre: KOL)
Well, it didn't take me anywhere near "16 months", but that's not the greatest measure. For me, I measured by the fact I only lost two battles in my first pass through. That's not very good, really; I expect better then that. This second time through the battles are almost perfunctory.
BTW, Hint: It's all about the heal, the only thing in these games (tactics RPGs and conventional RPGs) that have no real-world counterparts. (We can deal the damage out in the real world as much as you'd like; waving a magic wand and bringing a person from 1HP to 11,342HP in a single turn is a bit harder.) If you're really having trouble in Tactics Ogre for instance, stacking three healers on your team (including Knights with the heal spell) will win nearly any battle, though not necessarily quickly, as long as you keep your healers alive.
Ever noticed your enemies almost NEVER have heal, and even more rarely have "full heal"? (Yes, I know, it's been done, but it is rare; there's this one boss in Skies of Arcadia in the middle that has Full Heal; low probability but quite annoying when it fires when you've got one turn to go!) That's because they'd often be nearly unbeatable if they did; they'd CERTAINLY be unbeatable if they used it intelligently. Healing is the key.