Re:Ummm...Karma to Burn.
on
Linux 2.6.26 Out
·
· Score: 3, Insightful
Actually, let's try a more constructive approach.
``How about getting b,g,a working for standard (intel, broadcom, atheros) chipsets first.''
I'm sure it's being worked on. As for that happening _first_, I don't think that's a really good idea. To you, support for these chipsets may be very important, so important that it makes you feel bad if any features have been added, without adding supports for said chipsets, first. To others, these chipsets may not be so important. Those people would rather have other features added first. With the large number of people who are working on Linux, a lot of things can be worked on at the same time - but we can't hope to please everyone.
As for support for your chipsets - experience shows they will probably be supported someday, but it can take a long time. Exactly how long usually depends how cooperative the manufacturer of the chipset is, and how similar the chipset is to chipsets already supported. Both of these are under control of the manufacturer, so we are largely dependent on them.
``The same reason I get trolled and flamed, is the same reason that LINUX is never going to be more than a "hobby OS"''
I agree with you that flaming you isn't an appropriate response to your original post, which is clearly rooted in frustration. On the other hand, your attitude isn't exactly helpful, either. You complain about developers not supporting your favorite features - features that are probably hard for them to implement, because they are dependent on others who aren't cooperating - and tell them they should have supported your features instead of the many great features they did implement. Then you go on to claim - insultingly - that "LINUX is never going to be more than a \"hobby OS\"", which is clearly disingenious. Linux is being used professionally in many places. People are selling operating systems based on it, and devices with Linux on them. Clearly, it's already more than a hobby OS.
All in all, your complaint about lack of support for common network hardware is well-taken, and probably being worked on. It will take time, of course. Would you really have all other development on Linux halt while the drivers for your chipsets are developed? I don't think that would be wise. I understand (and share) your frustration, but I think the best course of action is:
1. Leave the developers to work on what they want to work on (possibly guided by suggestions from users) 2. For WLAN, choose chipsets that _are_ supported, and preferably with specifications available from the manufacturer. Support the manufacturers that support freedom of choice, not those that would lock you into proprietary software. 3. Express your frustration with the situation, but refrain from insulting people and using strong language. There's just no call for that.
Heh. And just the other day, I was thinking about 2-stroke and 4-stroke engines, and it hit me that there were probably a lot of other possibilities that could yield worthwhile results. Thanks for the link!
``That is not only acceptable to me, I think it should be the norm. I would hate to believe I was using Gentoo, Red Hat, or any other distribution for a period of time and then suddenly discover I was using a derivative, modified by whom and god knows how. When I see the Fox, I want to know that it is the same Firefox that I used yesterday on a completely different distribution (assuming the two are using the same version number.)''
This, of course, is exactly what trademarks are for.
In other words, routers are now at the same stage PCs have been in for ages. They've evolved from appliances into versatile devices with the bulk of the functionality in software - and a lot of the software is crap.
The Department of Homeland Security is just amazing. I admit I haven't been paying as much attention as I could have, but, so far, I have only heard about _one_ thing they did that I thought would actually...improve homeland security. For the rest, they have embarked on numerous projects that range from interesting to horrible, but that are all very expensive and do little to improve security.
On the one hand, I am glad to see a large portion of the money that DHS gets goes to interesting projects, rather than everything being spent on spying on innocent people. On the other hand, I am sad to see all the things that are done under the (_very_ thin) guise of security...
If the government wants to sponsor certain pet projects of theirs, why don't they just say they want to sponsor them, because they find them interesting, or some such, instead of trying to pretend it's all in the name of security?
``If so, then people are free to do whatever cybercrime they feel, claiming it was the neighbour.''
Yes, and? Is this a Bad Thing?
It's nothing really new. Just because the packets come from your network doesn't mean you had anything to do with them. Wireless doesn't change that. It may add additional vectors for people to use your network, possibly without you knowing, but those possibilities have always been there. Even if the packets can somehow be traced to your computer, that still doesn't mean it was you. It could be someone else using your computer. It could be a piece of malware that somehow got into your computer.
The real failing here, I feel, is not on the part of the people whose network is used, but on the services that fall victim to the criminals. At the very least, they have insufficient authentication. _They_ cannot establish who entered their service and commited the crimes. This means they trusted someone to perform these actions, without actually knowing who that someone was. This is their failing. If you completely locked down your network, kept track of exactly who was using your network to do what at what time, then you could help them find out who abused their trust and commited crimes, and that would be very nice of you, but I don't see why you should do their authentication for them, much less bear the blame for their failing.
To get back to your statement, you don't need to claim it was the neighbor. They claim it was you - let them come up with the proof. If all they have is an IP address which could as well be used by the neighbor or by a total stranger, they can't prove it was you. Perhaps they can use it to obtain a warrant to further investigate you, but that's about it. At least, that's how I see things.
Actually, these questions, to me, made it seem like a good interview.
For one, it shows the interviewer actually did his homework. He knows a lot about what he is talking about. How very different from reporters who go to interviews with almost zero knowledge, then try to make a story out of what they were told, and get it wrong. I've seen that happen far too many times.
For another, it puts the interviewee at ease. Some people get really nervous about interviews. If you ask them a few easy questions, they'll feel more comfortable.
Thirdly, it's a device that gets the interviewee talking, and talking about the things you are interested in hearing. You talk about technical things in the beginning, you will get technical stories out of the person you're interviewing. Talk about Mars, and you will get info about Mars.
So, what it boils down to, really, is that you trust the server you pull updates from. In itself, that is nothing new. What is new is pointing out some specific attack vectors that you open yourself to.
``Well, to feed the troll, I have a question, is there ANY man that fully follows what he preaches? I have yet to meet such a person.
Lying is bad, yet people who believe this, still lie. Stealing is bad, yet people still take what is not theirs.
My premise is everyone is hypocritical at some level. Everyone. I can ask a series of questions of anyone, say about 100 of them, which shows that people often make excuses for why they vary from the very rules they themselves want.''
Ok, ask me your questions. I am not claiming I am perfect, but I try hard to live by my principles, avoid being hypocritical, improve myself, and make up for the mistakes I make. So, ask me your questions. Help me find where I can still improve myself.
``It's not like the requirements to get a FISA warrant (someone with a pulse to stand in front of a secret court and say "gimme" at some point not necessarily before you started spying) were exactly onerous.''
And that's the problem we have gotten into since 9/11. We _had_ laws and mechanisms in place to get the Bad Guys. Now, we have let governments grant themselves the power and the legitimacy to go after everyone.
``I was under the impression that Obama is not perfect but that he would always admit if he was wrong and quickly qork towards the right direction.''
And one of the problems in USAmerican politics is that this will be used against you. You can't recognize you were wrong and fix your mistake without your opponents accusing you of "flip-flopping".
The way Protocol Buffers encode data is similar to how I have designed protocols in the past. But, of course, there are various ways to encode data. Some examples:
- Encode your data in human-readable form, using separators. E.g. s-expressions, CSV, XML, JSON.
- Encode your data using type, length, value tuples. E.g. some encodings in ASN.1.
- Encode your data using type, value (and length, if necessary) tuples. E.g. some encodings of ASN.1.
Then there are choices as to adding indices to quickly jump to interesting parts of the data or skip over uninteresting parts, mechanisms for forward compatibility, etc.
I wonder if anyone has done a comparison of various techniques that can be used in data interchange formats and their impacts on message size, parsing performance, and other interesting quantities.
``Maybe somebody can explain, but it doesn't seem like protocol buffers really have much advantages over JSON. It sounds like it is effectively just a binary format for JSON-like data''
That's your advantage right there. Without having done benchmarks to back up my statements, I dare claim that JSON is more verbose and slower to parse than Protocol Buffers.
``I used to have an attitude like that, but by definition anyone who behaves that way is obviously mentally ill, and probably a jail term is only going to make things worse for him. I'm not sure there is alternative though...''
I don't know how things work in the States, but, IMO, a jail sentence's primary purpose isn't to make things worse or better for the sentenced, but to keep dangerous people off the streets. Part of it, of course, is punishment, but even that has making society safer as its real purpose.
That does raise an interesting question, though. On the one hand, if he could do something as terrible as killing a former lover, would it be safe to have him loose? On the other hand, it seems to me Nina wasn't exactly angelic either - so maybe the risk of it happening again isn't actually all that large.
Interesting questions aside, I feel very bad about this whole history, and extend my sympathy to all involved, especially the children.
Actually, my thinking about chosing a filesystem _has_ been affected by this case, but for a different reason. Hans getting arrested has raised strong doubts in my mind about the continuity of ReiserFS. It still remains my favorite*, but I will be watching the developments and see if a better choice comes along at some point.
Hans being found guilty of murder somehow doesn't factor into the decision for me. I can see how it would, but it just doesn't, for me. If the filesystem is the best choice, I don't see why I would go with a lesser option, just because an important contributor committed murder. That isn't _my_ fault, after all.
* Strangely, where many others report problems with ReiserFS and suggest various alternatives, for me, ReiserFS has been both the fastest and the most reliable filesystem I've ever used.
While I agree with you that having good processes is a Good Thing, I vehemently disagree with "languages are just details" and "most developers have had a wide range of language exposure". Languages do vary (e.g. in expressive power, error detection before run time, and overall elegance/hairiness). Most developers I've seen only really know Java, and I've seen people struggle enormously to wrap their heads around something that differed from what they are used to.
In the end, it is good for your company to be flexible. One day, someone will figure out a better way to do what you are doing, using different tools than the ones you are using. Or maybe the kind of applications that you develop will fall out of fashion. If you are flexible enough, you can adapt to the new times - or perhaps even be ahead of the curve.
That doesn't mean that standardizing on a single set of tools is a Bad Thing. I think it's a good idea, as long as you develop applications that can be developed well using your chosen tools, and as long as you don't hurt developers too much by your choices. Do keep in mind, though, that you severely reduce your flexibility. Make sure you have your choice of tools reviewed regularly by people who actually have a good understanding of the other tools that are available, and change the policy in time. You don't want your company to become a one-trick horse whose trick nobody wants to see anymore.
``if Java really were released today, brand-new, would it be a tool you'd choose?''
No, I wouldn't. Back in the day, I did. I didn't know much yet and Java was pitched as being the great new thing that did things the best way. I bought into the religion.
Then I got disappointed. My programs were slow. The APIs didn't work the way I had expected them to work. It was needlessly verbose (Foo foo = new Foo()), needlessly ugly (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream("something")))), and had sillyness like "Iterator iter = people.iterator(); while(iter.hasNext()) { Person person = (Person) iter.next();... }".
Java has since improved. Since 1.5, it has been a lot better. But I have learned a lot more, as well.
I now know that there are *lots* of programming languages. I now know that I like some of these languages much more than I do Java. I also know that for every shortcoming I percieve in Java, there is another language that does it better. And even things that Java does well are often matched or exceeded by other languages.
I also know that, for all Java was touted as the Great New Thing, none of the things it "introduced" were actually new. It had all been done before. Of course, what was new was Java itself; the whole package. It lacked many things that other languages already had, and since then, a lot of time and effort has gone in designing and building things for Java that already existed for other languages and platforms.
I feel bitter about Java. Not because I think it is absolutely terrible, because I think it is a fairly decent language with a lot of good ideas in it. But I feel bitter, because I feel it has wasted a lot of time and led us away from what could have been. We already had great languages, great platforms, and great tools. The hype around Java eclipsed (no pun intended) all that and got amazing numbers of talented people to write tools for Java, add great ideas from other languages to Java, etc. etc. I still don't think it's there yet, and that has everything to do with the shortcomings of Java as a language and misguided decisions by designers - in general, most things in the Javaverse are terribly over-engineered. So, instead of working with the great things we had and making them even better, we've spent our effort getting something mediocre on par with that. I feel Java has been a huge setback in that respect.
On the other hand, Java _was_ actually an improvement for many. In that sense, I feel it, and its evangelists, deserve credit for _improving_ the world.
It's really a mixed bag. But on the whole, I resent it. I'll work with it on ocacssion, but I won't choose it. Not if I have the freedom to choose something better suited to the task.
I'm happy to see this. I have advocated this for years. TLDs just don't make any sense to me anymore. Now it's finally there. Never mind that it's probably just a way for them to make more money.
``You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability.''
I agree with everything you say, but this part is slightly off. The only way not to have to make that choice is if you don't have it. Maturity of the language (or the implementation, in this case) doesn't factor into it, because the code for new features will invariably be less mature than older code, regardless of how mature the rest of the implementation is.
Yes. Similarly, problems could conceivably occur if you submitted an URL with very many parameters, or a very long one.
But look at the magnitude required. You need an index of over 2^30 to trigger the problem. That's over a billion entries. To make an HTTP request that long, you would need to send over a gigabyte of data to the server. To encode that many parameters in the URL would require even larger volumes. And to cause your "add item" functionality to trigger the bug would require even larger volumes of data - you would need on the order of a billion requests.
Don't get me wrong, these are serious bugs that need to be fixed, but "exploitable from trivial user-specified parameters [in web applications]" is a bit rich.
Also worth noting is that proper checking _is_ performed in some cases:
$ irb irb(main):001:0> a = [] => [] irb(main):002:0> a[(1 << 31) -1] => nil irb(main):003:0> a[(1 << 31)] RangeError: bignum too big to convert into `long'
from (irb):3:in `[]'
from (irb):3
from:0 irb(main):004:0> a[(1 << 31)] = ?f RangeError: bignum too big to convert into `long'
from (irb):4:in `[]='
from (irb):4
from:0 irb(main):005:0> a[(1 << 31) - 1] = ?f (irb):5: [BUG] Segmentation fault ruby 1.8.5 (2006-08-25) [i486-linux]
zsh: abort irb
So, when _reading_ from the array, all is well. When the index is so large it doesn't fit in a 32-bit signed integer without wrapping around, all is well. But the problem is when _writing_ to an index that is large, but not so large as to be outright rejected.
Interesting.
I would venture to guess that they did an honest job of checking for problems with loss of precision (hence the exceptions when a too-large index is used), but didn't really consider all the operations that are performed with a finite-precision number once you have one. For example, if the actually memory address of an array element were "base address + couple of words + index", then that could end up causing integer overflow, even when the index is less than 2^31.
``If a black hole created by the LHC is interactive enough to destroy the world within the lifetime of the sun, similar black holes are already being created by cosmic rays. Such black holes would be stopped by dense cosmic objects (neutron stars and white dwarfs). A black hole stopped in one of these objects would eventually absorb it. We see sufficiently old neutron stars in the sky, thus any black hole that could be created at the LHC, even if it is stable, would have no effect on the earth on any meaningful timescale.''
Or so the theory goes, anyway. The truth is, we don't know what will happen. If we did, there would be no need to actually perform the experiment.
It's not just about processor time, but also about network latency. Adding encryption is likely to introduce a couple more round trips, which can be very noticeable, depending on the latency-sensitivity of an application and the way things are implemented.
Slashdot Mirror
Actually, let's try a more constructive approach.
``How about getting b,g,a working for standard (intel, broadcom, atheros) chipsets first.''
I'm sure it's being worked on. As for that happening _first_, I don't think that's a really good idea. To you, support for these chipsets may be very important, so important that it makes you feel bad if any features have been added, without adding supports for said chipsets, first. To others, these chipsets may not be so important. Those people would rather have other features added first. With the large number of people who are working on Linux, a lot of things can be worked on at the same time - but we can't hope to please everyone.
As for support for your chipsets - experience shows they will probably be supported someday, but it can take a long time. Exactly how long usually depends how cooperative the manufacturer of the chipset is, and how similar the chipset is to chipsets already supported. Both of these are under control of the manufacturer, so we are largely dependent on them.
``The same reason I get trolled and flamed, is the same reason that LINUX is never going to be more than a "hobby OS"''
I agree with you that flaming you isn't an appropriate response to your original post, which is clearly rooted in frustration. On the other hand, your attitude isn't exactly helpful, either. You complain about developers not supporting your favorite features - features that are probably hard for them to implement, because they are dependent on others who aren't cooperating - and tell them they should have supported your features instead of the many great features they did implement. Then you go on to claim - insultingly - that "LINUX is never going to be more than a \"hobby OS\"", which is clearly disingenious. Linux is being used professionally in many places. People are selling operating systems based on it, and devices with Linux on them. Clearly, it's already more than a hobby OS.
All in all, your complaint about lack of support for common network hardware is well-taken, and probably being worked on. It will take time, of course. Would you really have all other development on Linux halt while the drivers for your chipsets are developed? I don't think that would be wise. I understand (and share) your frustration, but I think the best course of action is:
1. Leave the developers to work on what they want to work on (possibly guided by suggestions from users)
2. For WLAN, choose chipsets that _are_ supported, and preferably with specifications available from the manufacturer. Support the manufacturers that support freedom of choice, not those that would lock you into proprietary software.
3. Express your frustration with the situation, but refrain from insulting people and using strong language. There's just no call for that.
Heh. And just the other day, I was thinking about 2-stroke and 4-stroke engines, and it hit me that there were probably a lot of other possibilities that could yield worthwhile results. Thanks for the link!
``That is not only acceptable to me, I think it should be the norm. I would hate to believe I was using Gentoo, Red Hat, or any other distribution for a period of time and then suddenly discover I was using a derivative, modified by whom and god knows how. When I see the Fox, I want to know that it is the same Firefox that I used yesterday on a completely different distribution (assuming the two are using the same version number.)''
This, of course, is exactly what trademarks are for.
In other words, routers are now at the same stage PCs have been in for ages. They've evolved from appliances into versatile devices with the bulk of the functionality in software - and a lot of the software is crap.
``Should the Linux Desktop Be "Pure?"''
There is no "the Linux Desktop". And if the question is if there should be one, the answer is no.
There should be choice. That way, those who want to have "pure" systems can do so. And those who have other preferences can have it their way.
The Department of Homeland Security is just amazing. I admit I haven't been paying as much attention as I could have, but, so far, I have only heard about _one_ thing they did that I thought would actually...improve homeland security. For the rest, they have embarked on numerous projects that range from interesting to horrible, but that are all very expensive and do little to improve security.
On the one hand, I am glad to see a large portion of the money that DHS gets goes to interesting projects, rather than everything being spent on spying on innocent people. On the other hand, I am sad to see all the things that are done under the (_very_ thin) guise of security...
If the government wants to sponsor certain pet projects of theirs, why don't they just say they want to sponsor them, because they find them interesting, or some such, instead of trying to pretend it's all in the name of security?
``If so, then people are free to do whatever cybercrime they feel, claiming it was the neighbour.''
Yes, and? Is this a Bad Thing?
It's nothing really new. Just because the packets come from your network doesn't mean you had anything to do with them. Wireless doesn't change that. It may add additional vectors for people to use your network, possibly without you knowing, but those possibilities have always been there. Even if the packets can somehow be traced to your computer, that still doesn't mean it was you. It could be someone else using your computer. It could be a piece of malware that somehow got into your computer.
The real failing here, I feel, is not on the part of the people whose network is used, but on the services that fall victim to the criminals. At the very least, they have insufficient authentication. _They_ cannot establish who entered their service and commited the crimes. This means they trusted someone to perform these actions, without actually knowing who that someone was. This is their failing. If you completely locked down your network, kept track of exactly who was using your network to do what at what time, then you could help them find out who abused their trust and commited crimes, and that would be very nice of you, but I don't see why you should do their authentication for them, much less bear the blame for their failing.
To get back to your statement, you don't need to claim it was the neighbor. They claim it was you - let them come up with the proof. If all they have is an IP address which could as well be used by the neighbor or by a total stranger, they can't prove it was you. Perhaps they can use it to obtain a warrant to further investigate you, but that's about it. At least, that's how I see things.
Actually, these questions, to me, made it seem like a good interview.
For one, it shows the interviewer actually did his homework. He knows a lot about what he is talking about. How very different from reporters who go to interviews with almost zero knowledge, then try to make a story out of what they were told, and get it wrong. I've seen that happen far too many times.
For another, it puts the interviewee at ease. Some people get really nervous about interviews. If you ask them a few easy questions, they'll feel more comfortable.
Thirdly, it's a device that gets the interviewee talking, and talking about the things you are interested in hearing. You talk about technical things in the beginning, you will get technical stories out of the person you're interviewing. Talk about Mars, and you will get info about Mars.
So, what it boils down to, really, is that you trust the server you pull updates from. In itself, that is nothing new. What is new is pointing out some specific attack vectors that you open yourself to.
Gmail has been silently dropping emails for as long as I remember. It's broken, and that's yet another reason I don't use it.
``Well, to feed the troll, I have a question, is there ANY man that fully follows what he preaches? I have yet to meet such a person.
Lying is bad, yet people who believe this, still lie. Stealing is bad, yet people still take what is not theirs.
My premise is everyone is hypocritical at some level. Everyone. I can ask a series of questions of anyone, say about 100 of them, which shows that people often make excuses for why they vary from the very rules they themselves want.''
Ok, ask me your questions. I am not claiming I am perfect, but I try hard to live by my principles, avoid being hypocritical, improve myself, and make up for the mistakes I make. So, ask me your questions. Help me find where I can still improve myself.
``It's not like the requirements to get a FISA warrant (someone with a pulse to stand in front of a secret court and say "gimme" at some point not necessarily before you started spying) were exactly onerous.''
And that's the problem we have gotten into since 9/11. We _had_ laws and mechanisms in place to get the Bad Guys. Now, we have let governments grant themselves the power and the legitimacy to go after everyone.
``I was under the impression that Obama is not perfect but that he would always admit if he was wrong and quickly qork towards the right direction.''
And one of the problems in USAmerican politics is that this will be used against you. You can't recognize you were wrong and fix your mistake without your opponents accusing you of "flip-flopping".
The way Protocol Buffers encode data is similar to how I have designed protocols in the past. But, of course, there are various ways to encode data. Some examples:
- Encode your data in human-readable form, using separators. E.g. s-expressions, CSV, XML, JSON.
- Encode your data using type, length, value tuples. E.g. some encodings in ASN.1.
- Encode your data using type, value (and length, if necessary) tuples. E.g. some encodings of ASN.1.
Then there are choices as to adding indices to quickly jump to interesting parts of the data or skip over uninteresting parts, mechanisms for forward compatibility, etc.
I wonder if anyone has done a comparison of various techniques that can be used in data interchange formats and their impacts on message size, parsing performance, and other interesting quantities.
``Maybe somebody can explain, but it doesn't seem like protocol buffers really have much advantages over JSON. It sounds like it is effectively just a binary format for JSON-like data''
That's your advantage right there. Without having done benchmarks to back up my statements, I dare claim that JSON is more verbose and slower to parse than Protocol Buffers.
``I used to have an attitude like that, but by definition anyone who behaves that way is obviously mentally ill, and probably a jail term is only going to make things worse for him. I'm not sure there is alternative though...''
I don't know how things work in the States, but, IMO, a jail sentence's primary purpose isn't to make things worse or better for the sentenced, but to keep dangerous people off the streets. Part of it, of course, is punishment, but even that has making society safer as its real purpose.
That does raise an interesting question, though. On the one hand, if he could do something as terrible as killing a former lover, would it be safe to have him loose? On the other hand, it seems to me Nina wasn't exactly angelic either - so maybe the risk of it happening again isn't actually all that large.
Interesting questions aside, I feel very bad about this whole history, and extend my sympathy to all involved, especially the children.
Actually, my thinking about chosing a filesystem _has_ been affected by this case, but for a different reason. Hans getting arrested has raised strong doubts in my mind about the continuity of ReiserFS. It still remains my favorite*, but I will be watching the developments and see if a better choice comes along at some point.
Hans being found guilty of murder somehow doesn't factor into the decision for me. I can see how it would, but it just doesn't, for me. If the filesystem is the best choice, I don't see why I would go with a lesser option, just because an important contributor committed murder. That isn't _my_ fault, after all.
* Strangely, where many others report problems with ReiserFS and suggest various alternatives, for me, ReiserFS has been both the fastest and the most reliable filesystem I've ever used.
Yes. It's always the kids who get the worst of the pain when the parents mess up. :-(
While I agree with you that having good processes is a Good Thing, I vehemently disagree with "languages are just details" and "most developers have had a wide range of language exposure". Languages do vary (e.g. in expressive power, error detection before run time, and overall elegance/hairiness). Most developers I've seen only really know Java, and I've seen people struggle enormously to wrap their heads around something that differed from what they are used to.
In the end, it is good for your company to be flexible. One day, someone will figure out a better way to do what you are doing, using different tools than the ones you are using. Or maybe the kind of applications that you develop will fall out of fashion. If you are flexible enough, you can adapt to the new times - or perhaps even be ahead of the curve.
That doesn't mean that standardizing on a single set of tools is a Bad Thing. I think it's a good idea, as long as you develop applications that can be developed well using your chosen tools, and as long as you don't hurt developers too much by your choices. Do keep in mind, though, that you severely reduce your flexibility. Make sure you have your choice of tools reviewed regularly by people who actually have a good understanding of the other tools that are available, and change the policy in time. You don't want your company to become a one-trick horse whose trick nobody wants to see anymore.
``if Java really were released today, brand-new, would it be a tool you'd choose?''
No, I wouldn't. Back in the day, I did. I didn't know much yet and Java was pitched as being the great new thing that did things the best way. I bought into the religion.
Then I got disappointed. My programs were slow. The APIs didn't work the way I had expected them to work. It was needlessly verbose (Foo foo = new Foo()), needlessly ugly (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream("something")))), and had sillyness like "Iterator iter = people.iterator(); while(iter.hasNext()) { Person person = (Person) iter.next(); ... }".
Java has since improved. Since 1.5, it has been a lot better. But I have learned a lot more, as well.
I now know that there are *lots* of programming languages. I now know that I like some of these languages much more than I do Java. I also know that for every shortcoming I percieve in Java, there is another language that does it better. And even things that Java does well are often matched or exceeded by other languages.
I also know that, for all Java was touted as the Great New Thing, none of the things it "introduced" were actually new. It had all been done before. Of course, what was new was Java itself; the whole package. It lacked many things that other languages already had, and since then, a lot of time and effort has gone in designing and building things for Java that already existed for other languages and platforms.
I feel bitter about Java. Not because I think it is absolutely terrible, because I think it is a fairly decent language with a lot of good ideas in it. But I feel bitter, because I feel it has wasted a lot of time and led us away from what could have been. We already had great languages, great platforms, and great tools. The hype around Java eclipsed (no pun intended) all that and got amazing numbers of talented people to write tools for Java, add great ideas from other languages to Java, etc. etc. I still don't think it's there yet, and that has everything to do with the shortcomings of Java as a language and misguided decisions by designers - in general, most things in the Javaverse are terribly over-engineered. So, instead of working with the great things we had and making them even better, we've spent our effort getting something mediocre on par with that. I feel Java has been a huge setback in that respect.
On the other hand, Java _was_ actually an improvement for many. In that sense, I feel it, and its evangelists, deserve credit for _improving_ the world.
It's really a mixed bag. But on the whole, I resent it. I'll work with it on ocacssion, but I won't choose it. Not if I have the freedom to choose something better suited to the task.
I'm happy to see this. I have advocated this for years. TLDs just don't make any sense to me anymore. Now it's finally there. Never mind that it's probably just a way for them to make more money.
``You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability.''
I agree with everything you say, but this part is slightly off. The only way not to have to make that choice is if you don't have it. Maturity of the language (or the implementation, in this case) doesn't factor into it, because the code for new features will invariably be less mature than older code, regardless of how mature the rest of the implementation is.
Yes. Similarly, problems could conceivably occur if you submitted an URL with very many parameters, or a very long one.
But look at the magnitude required. You need an index of over 2^30 to trigger the problem. That's over a billion entries. To make an HTTP request that long, you would need to send over a gigabyte of data to the server. To encode that many parameters in the URL would require even larger volumes. And to cause your "add item" functionality to trigger the bug would require even larger volumes of data - you would need on the order of a billion requests.
Don't get me wrong, these are serious bugs that need to be fixed, but "exploitable from trivial user-specified parameters [in web applications]" is a bit rich.
Also worth noting is that proper checking _is_ performed in some cases:
So, when _reading_ from the array, all is well. When the index is so large it doesn't fit in a 32-bit signed integer without wrapping around, all is well. But the problem is when _writing_ to an index that is large, but not so large as to be outright rejected.Interesting.
I would venture to guess that they did an honest job of checking for problems with loss of precision (hence the exceptions when a too-large index is used), but didn't really consider all the operations that are performed with a finite-precision number once you have one. For example, if the actually memory address of an array element were "base address + couple of words + index", then that could end up causing integer overflow, even when the index is less than 2^31.
``If a black hole created by the LHC is interactive enough to destroy the world within the lifetime of the sun, similar black holes are already being created by cosmic rays. Such black holes would be stopped by dense cosmic objects (neutron stars and white dwarfs). A black hole stopped in one of these objects would eventually absorb it. We see sufficiently old neutron stars in the sky, thus any black hole that could be created at the LHC, even if it is stable, would have no effect on the earth on any meaningful timescale.''
Or so the theory goes, anyway. The truth is, we don't know what will happen. If we did, there would be no need to actually perform the experiment.
It's not just about processor time, but also about network latency. Adding encryption is likely to introduce a couple more round trips, which can be very noticeable, depending on the latency-sensitivity of an application and the way things are implemented.