Actually, an ISP router will sometimes need to keep extra routing information based on what blocks you send packets to. I used to be part of the team running an IRC server on EFNet, and when we got attacked with a flood of faked packets, the problem was our return packets. When we sent return packets to too many places on the net, the router memory (on the border routers, IIRC) got overloaded. Bandwidth was (reasonably) easy to handle.
On the other hand, I seem to remember that problem going away maybe 4 years ago, after having upgraded router memory capacity.
That's probably a good idea; I'd not thought of it. So far, I've only showed it to individuals because I've been thinking of getting it academically published; I'll think a bit more on it (specifically, check how much work it would be to publish it) and then probably send it to LtU.
I've written a draft on a paper on adding "more typing" to Ruby. By "more typing", I actually mean every way I've been able to find of changing typing handling for the better: Invariant checks, concrete type inference, type declarations, interfaces, etc. The paper goes through the benefits and drawbacks of each possibility in "more typing", as a survey paper with background. As a result, there's also one new system (or at least something I've not seen anywhere else).
Would you be interested in doing a review? You can reach me at eeklund at gmail.com.
The "makes things more reliable" assumes that it's the same amount of work to develop in a language with type declarations as it is to develop in a dynamically typed language.
If it's less work to develop without type declarations - and my experience is that it usually is - then the increased development velocity gives more time for writing tests. This make things more reliable in the dynamic languages (well, really in my experience in Ruby - Perl has so many evil traps...)
I'm trying to find out the contexts where static typing actually save work. What areas/contexts have you worked in, and how much have you programmed in (what) dynamic languages?
I personally used to believe static typing caught bugs, until I started adding type checks to Ruby. This wasn't static typing, just type declarations that were checked dynamically, yet they were intergrated and I found the hits against them with my testsuite, giving about the same speed of check as running a compiler. I found that while I was developing, I was always hitting against them with things that were inappropriate. They did not catch any bugs for me - they just had to be changed all the time for non-bugs.
On the other hand, there are clearly cases where types are necessary. They're crucially necessary at the "edges" of programs, for instance. You cannot talk to hardware without, in the end, breaking it down to particular bits hitting particular memory areas. And when you're talking to other computers, you also need to send a particular set of bits over - untyped data just can't do the job.
I suspect there may a documentation benefit for the edge (interface) of modules when working with several people; I've just not seen much of it yet.
For the future, I'm fairly sure there could be a much more floating line between 'static' and 'dynamic' typing, using higher level invariants, optional declarations, and various types of concrete type inference. However, before we can find the sweet spot for that, I think we need to know where we're getting our benefits...
Eivind.
Re:Dynamic typing
on
Beyond Java
·
· Score: 2, Insightful
The elite programmers I know tend to choose which language is appropriate for which project. I can't think of any I'd consider "elite" that program less than 3 languages.
And I've seen much more chaotic code in Java than in Ruby; chaos isn't a function of static or dynamic typing. It is mostly a function of programmer and manager competence, though also a function of the surrounding culture and what the language makes easy. Perl, for instance, tend to encourage halfassed programming.
Eivind.
Re:(ot-ish) Perl is not too loose and messy
on
Beyond Java
·
· Score: 1
I've been pondering this for ten years. Perl is messy because it adds a bunch of useless special cases, uses obscure, context-ridden, hard to read syntax for a lot of operations, use special functions instead of having object methods, lack exceptions, have instanced and referenced hashes/arrays, give special varying treatment to function parameters depending on how the function is declared, lack proper type differences between numbers and strings, has an undef that only semi-works, and have make up hash references on its own (called autovivification.)
There's some more evil in there, too, yet the above cover most of it. If you have a free choice, choose Ruby.
What I describe is the way it works for online transactions in Norway as of today. I've implemented this against two different providers, and we have a period where the reservation can be kept open, and then we run capture (take the money) when the shipment is going out. If we DON'T run capture, the reservation is automatically released.
You're describing a credit based system; VISA here mostly run debit cards. You're describing a day-by-day system; everything here is online, and the banks cooperate. The money is directly deducted from your bank account at the moment we capture.
Eivind.
Re:Dude, it's just a pre-order, not a pre-purchase
on
The Optimus Mini Keyboard
·
· Score: 3, Informative
I don't know about laws - I *do* know about agreements, though, as I've coded this stuff for customers. Credit card payments work as a two phase system. In phase 1, when the customer orders, you reserve the funds from the customer account. This "feels like" a charge - the money isn't available for your use any more.
Then, you pack up and make the order ready for shipment. When you have the stuff assembled in a box and ready to ship to the customer, you "capture" the payment. This is when you actually get the money, and things can fail at this point too (e.g, if the card had been stolen.)
Capturing the money before you're shipping the order is definately against the agreements used - I'm not sure if it is illegal or not.
There's also some maximum amount of time you can keep the funds reserved - I think this vary by agreement, too.
So, you don't get the money until you're shipping the order, unless you use a factoring company or similar. A factoring company (usually) lends you money against the right to collect on your bills, and cancels the debt as the bills are paid. They're often also collection agencies, and they're normally in the black, so they can grab tax credits for losses etc - thus making the bills more worth to them than to you.
abuse@ is one of the standard mail addresses from the Internet standard RFC2822 (I think it was in 2822 the standard names were, anyway). In my opinion, PayPal is being irresponsible.
There is a LOT of other code that does not risk `data lock in, either. For instance, my text editors are principally exchangable. Trying to separate on the game/non-game barrier will be difficult, I think - a lot of people would try to fit in as "game".
We also have the problem of handling services - e.g. Yahoo! mail - and that's actually much more icky, I think. What do I do when I can't get my mail out of Yahoo! mail?
From my point of view, it Gates' destruction of value through his thefts (the illegal market manipulation) is much, much larger than the amount he's given. I believe the balance is clearly net negative, alsofor the poor countries.
Of course, that's all odds - yet that's the best it's possible to do. Gates played the odds - in violation of the rules we've set up, both ethically and legally - in order to enrich himself and his company. In order to get the feeling of winning at his game, he destroyed things for everybody. That he then gives some of the wealth he stole back to some of those he's destroyed things for does not, in my book, make up for doing the evil in the first place.
By doing vertex/object elimination on the server side and transferring only relevant coordinates.
That would lead to incredibly low or laggy framerates, as you couldn't update the screen until the next frames set of co-ordinates had come down from the server.
You only do it for monsters (active objects, including player characters) that the players shouldn't be able to see. If the lag problem turned out to be too big, I'd preload a few possibilities for movement change. That would let the end engine just select among them. With collision detection (including all forms of hits) done server-side, and extra chaff (neutral data) thrown in alongside the legitimate data, I think this would be quite difficult to defeat.
It'd also make it very awkward to do in-world mirrors.
No, that's just a vector turn in your object eliminator. Then feed all coordinates that would be visible in the mirror.
Graphics accelerators are designed to do that sort of clipping very rapidly and they should be able to do their job.
Sure, I know that. A generic PC just can't do what is needed of it today, though perhaps things like LaGrange will fix it.
I heartfully hope not. That would mean I no longer had a generic computer, and no longer owned my own computer - instead, it would be controlled by media requirements.
ENTERTAINMENT is not worth that. And I see anybody that work towards it as being personally evil. They are selling the privacy, the control, the soul of EVERYBODY for the latest fix of their drug.
Game code is materially different from productivity software. It's a pure entertainment product.
While I see no particular reason to excempt that kind of code, it's a quite different beast than productivity software. There's no compelling reason to force licensing of game code, while there is a compelling reason for productivity software.
No, the code is NOT what makes them money. This is a common misunderstanding.
What makes them money is licensing to customers the right to use derivatives of the code, and to a degree their change velocity, allowing them to do this several times. Even with the full rights for each customer to maintain their code - probably even with the right for customers to *share* changes - the holders of the source would not be able to match the change velocity of Microsoft.
And if they are, Microsoft only lose out in only being able to sell one copy to each person (or number-of-employees copies to each company). Because the customers don't want or need more. And I feel that is fine, too.
Oh, and I live off the revenues of selling software I write, and plan to continue doing so.
My view (as a programmer, former games programmer, former security consultant, former black hat, etc) is that that's basically though luck - it's not good enough game design, and that's that. Do not assume client security; upon assuming client security, do not pass goal, do not collect $200.
This attitude angers me. Do not assume client security? Do you know anything about how games like WoW or CounterStrike work? How exactly are you supposed to build a game which rewards the ability to sneak around when a hacked GL driver can make walls semi-transparent?
By doing vertex/object elimination on the server side and transferring only relevant coordinates. Elimination is a a standard technique, the reason to do it client side is to minimize server load. You get a slight increase in sensitivity (complete edge cases are handled right); I believe that could be resolved with transferring "virtual" coordinates for a bunch of different stuff, valid for a few frames forward, msking sure there's more than just player coordinates being bunched around.
How exactly can you build a game in which enforcing rules in real time is impossible? Do you seriously think everybody should go back to the days of turn based games?
I have no idea what you're talking about. The only problem with enforcing rules in real time is the speed of light, which prohibits e.g. running fighting games between the US and Europe, due to necessary latency. There *can* be a problem with client bandwidth, of course - alas, there's no simple way to fix that.
The real problem is the assumption of client security - there is no client security on a general purpose computer. Forget it. If people like me want to break security, we plug an ICE in instead of CPU, or run the stuff on a simulator, or find the crypto, decipher the data stream, and analyze the protocol. If you want to make breaking things more than a left hand job, you'll have to add in tamper resistant hardware. With that, you can make an attack not quite that trivial. Not impossible, though - there's a reason we call it "Tamper resistant" and not "tamper proof".
For various reasons (and excepting breaking serious tamper-resistant hardware), I've done all of the above during various forms of development. I've also reverse engineered entire commercial products to source code for modification.
Besides, in the question of morals, ALL players of WoW is by definition immoral, in that they're supporting Windows only software, thereby supporting MS. The fact that Blizzard has the GALL to make money off of illegal monopolizing...;)
To me, game cheats is and will remain small fry. Though I think it's a somewhat shitty thing to do, they're nowhere near up there with the behaviour of the big media companies or MS/Intel, and I have a hard time deciding between those companies and real black hats, who tend to destroy for millions regularly.
That's very much a point of view issue. Most people that aren't gamers would disagree, I think.
In my book, it's not a black hat issue. Black hats steal, destroy, and break laws. Game cheats mostly do not do this. What they do is create a tool for helping a user. Sure, this mess with game balance, as long as the game is based on the user having limited reaction ability etc. My view (as a programmer, former games programmer, former security consultant, former black hat, etc) is that that's basically though luck - it's not good enough game design, and that's that. Do not assume client security; upon assuming client security, do not pass goal, do not collect $200.
The hat isn't quite white, though - it's got a slight tint of brown in there, and the behaviour smells a bit...
Norway: It's legal to work up to 200 hours of overtime per year, expandable to 400 hours if you apply to the state.
Standard is 7.5 hours per day (8 hours with 30 minute lunch break), with a significant number of unionized workers having negotiated 15 minutes less.
In the private IT sector, it is fairly common to work 10 hours, even though that's illegal. The work environment inspection (Arbeidsmiljøtilsynet) check for this occasionally, and will fine both the employer and the employee heavily if these rules are broken. I know one guy that this has happened to. As I've not heard of any others, I think it's fairly uncommon.
There's a correlation between extreme creativity and schizophrenia. The combination of high intelligence and high creativity create the achievements many of our obviously intelligent people, which gives a sampling bias.
Apart from that, I think there is a correlation between high intelligence and eccentrity. However, I don't think that's due to "problems" - I think it's due to those with high intelligence being able to work around the problems that being eccentric brings, so they/we are more likely to remain eccentric. I believe high intelligence also correlates with more independent judgment, which would also feedback to more eccentricity.
It isn't a monopoly on IDEAS. It's a monopoly on a set of expressions of ideas.
There is definately a difference, yet both patents and copyrights are still state-granted monopolies. There is a bit of competition in the form of a lot of *other* monopolies (other music, other movies) and alternative entertainment (I prefer books, myself:) - yet it's still a monopoly.
I used to think this way. Alas, looking at it, I've found that I *don't* want Perl's libraries for Ruby. Perl's libraries would sit like a big lump of lead in there, impossible to deal with gracefully. Because they're *Perl* libraries. They're designed to Perl conventions, relying on basic Perl functionality. This is significantly different from Ruby conventions, with basic Ruby functionality.
So, to have the libraries work at all well, it would basically be necessary to port them anyway - or at least create a compatibility layer in the "borrowing" language. At that point, the benefits start diminishing.
Especially since my experience with CPAN is markedly different from yours. I don't consider it "well maintained" at all. I consider that when I grab something off CPAN, I will most likely have to maintain it myself, with an exception for a few of the major, well-known libraries. And even those don't always have something that approach maintenance. For example, it took me a year to get a serious bug fixed in the localization library - a major feature didn't work at all - and I provided ready-to-apply patches.
To make CPAN work for us in practice in production, running the same software on more than one machine, we've had to do a bunch of magic around the download process, including fixating versions (instead of using the newest version at all times), adding the ability to apply patches as we install, and moving some of the libraries into our local version control repository for local maintenance.
Slashdot Mirror
On the other hand, I seem to remember that problem going away maybe 4 years ago, after having upgraded router memory capacity.
Eivind.
Thanks!
Eivind.
Would you be interested in doing a review? You can reach me at eeklund at gmail.com.
Eivind.
If it's less work to develop without type declarations - and my experience is that it usually is - then the increased development velocity gives more time for writing tests. This make things more reliable in the dynamic languages (well, really in my experience in Ruby - Perl has so many evil traps...)
Eivind.
I personally used to believe static typing caught bugs, until I started adding type checks to Ruby. This wasn't static typing, just type declarations that were checked dynamically, yet they were intergrated and I found the hits against them with my testsuite, giving about the same speed of check as running a compiler. I found that while I was developing, I was always hitting against them with things that were inappropriate. They did not catch any bugs for me - they just had to be changed all the time for non-bugs.
On the other hand, there are clearly cases where types are necessary. They're crucially necessary at the "edges" of programs, for instance. You cannot talk to hardware without, in the end, breaking it down to particular bits hitting particular memory areas. And when you're talking to other computers, you also need to send a particular set of bits over - untyped data just can't do the job.
I suspect there may a documentation benefit for the edge (interface) of modules when working with several people; I've just not seen much of it yet.
For the future, I'm fairly sure there could be a much more floating line between 'static' and 'dynamic' typing, using higher level invariants, optional declarations, and various types of concrete type inference. However, before we can find the sweet spot for that, I think we need to know where we're getting our benefits...
Eivind.
And I've seen much more chaotic code in Java than in Ruby; chaos isn't a function of static or dynamic typing. It is mostly a function of programmer and manager competence, though also a function of the surrounding culture and what the language makes easy. Perl, for instance, tend to encourage halfassed programming.
Eivind.
There's some more evil in there, too, yet the above cover most of it. If you have a free choice, choose Ruby.
Eivind.
Eivind.
You're describing a credit based system; VISA here mostly run debit cards. You're describing a day-by-day system; everything here is online, and the banks cooperate. The money is directly deducted from your bank account at the moment we capture.
Eivind.
Then, you pack up and make the order ready for shipment. When you have the stuff assembled in a box and ready to ship to the customer, you "capture" the payment. This is when you actually get the money, and things can fail at this point too (e.g, if the card had been stolen.)
Capturing the money before you're shipping the order is definately against the agreements used - I'm not sure if it is illegal or not.
There's also some maximum amount of time you can keep the funds reserved - I think this vary by agreement, too.
So, you don't get the money until you're shipping the order, unless you use a factoring company or similar. A factoring company (usually) lends you money against the right to collect on your bills, and cancels the debt as the bills are paid. They're often also collection agencies, and they're normally in the black, so they can grab tax credits for losses etc - thus making the bills more worth to them than to you.
Eivind.
Eivind.
We also have the problem of handling services - e.g. Yahoo! mail - and that's actually much more icky, I think. What do I do when I can't get my mail out of Yahoo! mail?
Eivind.
Of course, that's all odds - yet that's the best it's possible to do. Gates played the odds - in violation of the rules we've set up, both ethically and legally - in order to enrich himself and his company. In order to get the feeling of winning at his game, he destroyed things for everybody. That he then gives some of the wealth he stole back to some of those he's destroyed things for does not, in my book, make up for doing the evil in the first place.
Eivind.
Of course, in order to truly get it you'll require a grounding in economics.
Eivind.
You only do it for monsters (active objects, including player characters) that the players shouldn't be able to see. If the lag problem turned out to be too big, I'd preload a few possibilities for movement change. That would let the end engine just select among them. With collision detection (including all forms of hits) done server-side, and extra chaff (neutral data) thrown in alongside the legitimate data, I think this would be quite difficult to defeat.
It'd also make it very awkward to do in-world mirrors.
No, that's just a vector turn in your object eliminator. Then feed all coordinates that would be visible in the mirror.
Graphics accelerators are designed to do that sort of clipping very rapidly and they should be able to do their job.
Sure, I know that. A generic PC just can't do what is needed of it today, though perhaps things like LaGrange will fix it.
I heartfully hope not. That would mean I no longer had a generic computer, and no longer owned my own computer - instead, it would be controlled by media requirements.
ENTERTAINMENT is not worth that. And I see anybody that work towards it as being personally evil. They are selling the privacy, the control, the soul of EVERYBODY for the latest fix of their drug.
Eivind.
Eivind.
While I see no particular reason to excempt that kind of code, it's a quite different beast than productivity software. There's no compelling reason to force licensing of game code, while there is a compelling reason for productivity software.
Eivind.
What makes them money is licensing to customers the right to use derivatives of the code, and to a degree their change velocity, allowing them to do this several times. Even with the full rights for each customer to maintain their code - probably even with the right for customers to *share* changes - the holders of the source would not be able to match the change velocity of Microsoft.
And if they are, Microsoft only lose out in only being able to sell one copy to each person (or number-of-employees copies to each company). Because the customers don't want or need more. And I feel that is fine, too.
Oh, and I live off the revenues of selling software I write, and plan to continue doing so.
Eivind.
Eivind.
By doing vertex/object elimination on the server side and transferring only relevant coordinates. Elimination is a a standard technique, the reason to do it client side is to minimize server load. You get a slight increase in sensitivity (complete edge cases are handled right); I believe that could be resolved with transferring "virtual" coordinates for a bunch of different stuff, valid for a few frames forward, msking sure there's more than just player coordinates being bunched around.
How exactly can you build a game in which enforcing rules in real time is impossible? Do you seriously think everybody should go back to the days of turn based games?
I have no idea what you're talking about. The only problem with enforcing rules in real time is the speed of light, which prohibits e.g. running fighting games between the US and Europe, due to necessary latency. There *can* be a problem with client bandwidth, of course - alas, there's no simple way to fix that.
The real problem is the assumption of client security - there is no client security on a general purpose computer. Forget it. If people like me want to break security, we plug an ICE in instead of CPU, or run the stuff on a simulator, or find the crypto, decipher the data stream, and analyze the protocol. If you want to make breaking things more than a left hand job, you'll have to add in tamper resistant hardware. With that, you can make an attack not quite that trivial. Not impossible, though - there's a reason we call it "Tamper resistant" and not "tamper proof".
For various reasons (and excepting breaking serious tamper-resistant hardware), I've done all of the above during various forms of development. I've also reverse engineered entire commercial products to source code for modification.
Besides, in the question of morals, ALL players of WoW is by definition immoral, in that they're supporting Windows only software, thereby supporting MS. The fact that Blizzard has the GALL to make money off of illegal monopolizing... ;)
To me, game cheats is and will remain small fry. Though I think it's a somewhat shitty thing to do, they're nowhere near up there with the behaviour of the big media companies or MS/Intel, and I have a hard time deciding between those companies and real black hats, who tend to destroy for millions regularly.
Eivind.
In my book, it's not a black hat issue. Black hats steal, destroy, and break laws. Game cheats mostly do not do this. What they do is create a tool for helping a user. Sure, this mess with game balance, as long as the game is based on the user having limited reaction ability etc. My view (as a programmer, former games programmer, former security consultant, former black hat, etc) is that that's basically though luck - it's not good enough game design, and that's that. Do not assume client security; upon assuming client security, do not pass goal, do not collect $200.
The hat isn't quite white, though - it's got a slight tint of brown in there, and the behaviour smells a bit...
Eivind.
Standard is 7.5 hours per day (8 hours with 30 minute lunch break), with a significant number of unionized workers having negotiated 15 minutes less.
In the private IT sector, it is fairly common to work 10 hours, even though that's illegal. The work environment inspection (Arbeidsmiljøtilsynet) check for this occasionally, and will fine both the employer and the employee heavily if these rules are broken. I know one guy that this has happened to. As I've not heard of any others, I think it's fairly uncommon.
Eivind.
Apart from that, I think there is a correlation between high intelligence and eccentrity. However, I don't think that's due to "problems" - I think it's due to those with high intelligence being able to work around the problems that being eccentric brings, so they/we are more likely to remain eccentric. I believe high intelligence also correlates with more independent judgment, which would also feedback to more eccentricity.
Eivind.
There is definately a difference, yet both patents and copyrights are still state-granted monopolies. There is a bit of competition in the form of a lot of *other* monopolies (other music, other movies) and alternative entertainment (I prefer books, myself :) - yet it's still a monopoly.
Eivind.
So, to have the libraries work at all well, it would basically be necessary to port them anyway - or at least create a compatibility layer in the "borrowing" language. At that point, the benefits start diminishing.
Especially since my experience with CPAN is markedly different from yours. I don't consider it "well maintained" at all. I consider that when I grab something off CPAN, I will most likely have to maintain it myself, with an exception for a few of the major, well-known libraries. And even those don't always have something that approach maintenance. For example, it took me a year to get a serious bug fixed in the localization library - a major feature didn't work at all - and I provided ready-to-apply patches.
To make CPAN work for us in practice in production, running the same software on more than one machine, we've had to do a bunch of magic around the download process, including fixating versions (instead of using the newest version at all times), adding the ability to apply patches as we install, and moving some of the libraries into our local version control repository for local maintenance.
Eivind.