I noticed that there is a list of new functionality going into the new version of Ingres.
Are you expecting a significant amount of new functionality to be integrated into Ingres because of the open-source effort, or are you expecting the open-source developers to focus more on tightening security, fixing bugs, and optimizing code?
Finite State Automata, discrete mathematics, knowledge of performance metrics (and how to tune algorithms for better performance), and knowledge of how compilers, operating systems, and assemblers are built are just a few things that separate programmers from computer scientists. This is why we've got so many, er, pieces, of software out there. They're not engineered, they're just slopped together.
There's a reason why all that "useless" stuff is taught to CS majors.
Right now, it takes either a certification or a degree to be considered skilled enough to program professionally, in most cases. It really pisses me off that my profession can be equated to an unskilled, uneducated factory worker. I gotta agree with the Nissan Maxima analogy above.
At any rate, there is a lot of crappy software out there. Just like there are a lot of crappy car manufacturers. There are a lot of crappy products, and they are the products that don't last. The products that do last are the ones that are engineered properly. Software is no exception. And having been in the software industry more than two days shows me that there are a lot of software engineers that make some pretty poorly engineered code.
Really, the writing of software comes in three flavors, and none of them lend themselves to assembly-line production. These are:
Build this new thing
Change this thing (faster, prettier, or more functionality - usually)
Fix this bug
Equate that with assembly-line car manufacturing. It just doesn't fit (you insensitive clod!).
I must agree. The functionality is there in Linux to do whatever the heck the developer/user wants, which is to say much more than windows has, but that functionality isn't very easily accessible.
The beauty of Linux (and Unix) is that its functionality is essentially transparent from the ground up. Windows 'hides' stuff.
The truth is, we need standards, standards, and more standards. And we need adherence to those standards. Until the big vendors start adhering to some sort of standards, software and hardware manufacturers are not going to jump through all the hoops necessary to get Linux-supported stuff out the door.
The big things that are hampering Linux:
1. X - it's bloated, and hard to deal with
2. Window management - standardize!
3. CLI - no matter how many zealots there are, plain-ol' users want clicky stuff. They don't want to configure anything with the command-line
4. CLI, part 2 - Linux/Unix was built oriented to the command-line. There needs to be an acceptable GUI equivalent of almost every standard *nix CLI app.
5. Linux community élitism - Rather than waiting for the world to change, and for all people to become Linux geeks, make Linux more attractive! People want to do what they need to do. The OS should help them get there. Should someone be required to know about TCP/IP before using a web browser? No. Then why should we expect them to learn about the CLI and memorize a bunch of commands so that they can organize their picures and.doc files into categorized directories?
Really, the length and frustration of the testing phase has an inverse relationship to the detail in the design (and adherence to the design). The better you design it, the easier the testing is.
Modularize!
Unit test per-module!
That way, you can use a process of elimination:
"The bug isn't here, we tested this module thoroughly."
It also helps to enforce design docs to be made as engineers write. That way, you know exactly what the code is doing when you test it. Otherwise, it's hard to identify border cases, bottlenecks, etc.
Shouldn't the idea be to decrease road rage?
It's a great novelty idea, but nothing more. As someone already mentioned, it distracts drivers from watching the road. That's partly the reason why there are many restrictions (at least, in the US) about blinking lights, moving parts, etc., on vehicles.
Personally, I think the little spinny-things on the rims are annoying enough, and I'm not looking forward to the car giving me the same head-tilted-back, lower-lip-stuck-out, looking-out-from-under-a-goofy-looking-hat, I-wanna-be-like-the-rappers-on-TV expression as the driver.
Not true. This b*****d lied. Try this (and I'm on XP SP1):
enter in the value 1.e-47
Add one.
Subtract one.
Should'nt this give you back 1.e-47? Well, it should, if the calculator had infinite precision, but it doesn't. It gives you back zero.
It'll give you the right answer if you use 1.e-46.
Slashdot Mirror
I noticed that there is a list of new functionality going into the new version of Ingres.
Are you expecting a significant amount of new functionality to be integrated into Ingres because of the open-source effort, or are you expecting the open-source developers to focus more on tightening security, fixing bugs, and optimizing code?
...when you replace developers with lawyers.
Finite State Automata, discrete mathematics, knowledge of performance metrics (and how to tune algorithms for better performance), and knowledge of how compilers, operating systems, and assemblers are built are just a few things that separate programmers from computer scientists. This is why we've got so many, er, pieces, of software out there. They're not engineered, they're just slopped together.
There's a reason why all that "useless" stuff is taught to CS majors.
At any rate, there is a lot of crappy software out there. Just like there are a lot of crappy car manufacturers. There are a lot of crappy products, and they are the products that don't last. The products that do last are the ones that are engineered properly. Software is no exception. And having been in the software industry more than two days shows me that there are a lot of software engineers that make some pretty poorly engineered code.
Really, the writing of software comes in three flavors, and none of them lend themselves to assembly-line production. These are:
- Build this new thing
- Change this thing (faster, prettier, or more functionality - usually)
- Fix this bug
Equate that with assembly-line car manufacturing. It just doesn't fit (you insensitive clod!).I must agree. The functionality is there in Linux to do whatever the heck the developer/user wants, which is to say much more than windows has, but that functionality isn't very easily accessible.
.doc files into categorized directories?
The beauty of Linux (and Unix) is that its functionality is essentially transparent from the ground up. Windows 'hides' stuff.
The truth is, we need standards, standards, and more standards. And we need adherence to those standards. Until the big vendors start adhering to some sort of standards, software and hardware manufacturers are not going to jump through all the hoops necessary to get Linux-supported stuff out the door.
The big things that are hampering Linux:
1. X - it's bloated, and hard to deal with
2. Window management - standardize!
3. CLI - no matter how many zealots there are, plain-ol' users want clicky stuff. They don't want to configure anything with the command-line
4. CLI, part 2 - Linux/Unix was built oriented to the command-line. There needs to be an acceptable GUI equivalent of almost every standard *nix CLI app.
5. Linux community élitism - Rather than waiting for the world to change, and for all people to become Linux geeks, make Linux more attractive! People want to do what they need to do. The OS should help them get there. Should someone be required to know about TCP/IP before using a web browser? No. Then why should we expect them to learn about the CLI and memorize a bunch of commands so that they can organize their picures and
Really, the length and frustration of the testing phase has an inverse relationship to the detail in the design (and adherence to the design). The better you design it, the easier the testing is. Modularize! Unit test per-module! That way, you can use a process of elimination: "The bug isn't here, we tested this module thoroughly." It also helps to enforce design docs to be made as engineers write. That way, you know exactly what the code is doing when you test it. Otherwise, it's hard to identify border cases, bottlenecks, etc.
Yep, I knew it. This supposed "Appreciation Day" is just another BOFH excuse to delay or deny service.
Shouldn't the idea be to decrease road rage? It's a great novelty idea, but nothing more. As someone already mentioned, it distracts drivers from watching the road. That's partly the reason why there are many restrictions (at least, in the US) about blinking lights, moving parts, etc., on vehicles. Personally, I think the little spinny-things on the rims are annoying enough, and I'm not looking forward to the car giving me the same head-tilted-back, lower-lip-stuck-out, looking-out-from-under-a-goofy-looking-hat, I-wanna-be-like-the-rappers-on-TV expression as the driver.
Not true. This b*****d lied. Try this (and I'm on XP SP1):
enter in the value 1.e-47
Add one.
Subtract one.
Should'nt this give you back 1.e-47? Well, it should, if the calculator had infinite precision, but it doesn't. It gives you back zero.
It'll give you the right answer if you use 1.e-46.