NT based Windows is primarily unstable when in low memory or low diskspace conditions, which may happen if you're running too many apps. I've found that Windows and Windows apps usually handle these situations poorly - especially with disk space, where the errors sometimes are meaningless or confusing.
You can't just blame Windows here - Windows allows apps reliable control of their memory space like just about any other modern OS (But not Linux - it will pick a process & kill it when it runs out of memory rather than failing allocations).
The fact of the matter is writing code that can handle running Out Of Memory (OOM) is very hard to get right. Consequentially if you haven't tested your program to handle OOM it most likely doesn't. The more memory allocation you do the more likely this is true. Great example: developer ASSERTs an allocation succeeds (but that's gone in the retail build). Hit a NULL reference exception, app goes poof.
Finally it's really hard to test for, so most people probably don't do it. Chalk it up to another reason software sucks and still crashes: people don't test for these "corner cases" (hah, tell that to the person writing their paper who doesn't know how to save). And it's certainly worse that an OS would consider it acceptable to take away the chance to operate correctly from the developer.
And as far as the second one goes I couldn't even find how to get to the journals without a user account. If people want to see Google index these they'll need to talk to the web site authors who choose to prevent Google from doing so.
Shadow government, controllers, bad guys with a worse agenda, at high order giving levels where the over-all picture can be kept from the lower level workers.
There's so much of that stuff now that you can't keep up with it. People are quick to dismiss it as "conspiracy theory".
And how do we know YOU'RE not part of the conspiracy? Maybe you're just a worker spouting disinformation so we don't discover the TRUTH? Maybe you're working for multiple governments, loyal to no one but yourself, spouting disinformation to all! Or maybe not.
Wow, you said a lot, and didn't really describe anything very well.
First you're blending inlining and macros. Beginning with "Inlining works like this" and ending with "since inlining doesn't work anyway" you're talking about macros. Your next paragraph talks about inlining - in that a JIT can perform this optimization. But nearly all compilers perform this simple optimization all the time, including a JIT, because it's also a compiler.
So, now that we all know that inlining is moving functions inline within other functions, either by programmer or compiler, we can move onto macros, which the bulk of your post discusses. The idea that "today's cut and paste GUI IDEs" can replace macros is insane. Macros provide a feature that functions cannot. While your trivial examples (and your quote was originally about C, yet your code is not C) don't demonstrate this at all. A more common example would be "#define max(a,b) ((a)>(b))?(a):(b)"
This is an extremely typical use of a macro. And it's bad & wrong. A function would be much better here, would be inlined by the compiler (in either Java or a traditional compiler), and wouldn't have problems when you did "foo = max(x++,y++);" where you end up doing an accidental double increment.
So, a little off topic, but macros do provide functionality that is not otherwise available. As one of your snippets begins to show it allows you to redefine the language. For example, let's say I want to add exception handling to C. I make a few macros:
Sure, it's primitive, but I also spent 5 minutes typing it into a little tiny window on Slashdot, so what do you expect? If you work with it you can do more. You could get crazy & start using setjmp & longjmp for your error handling needs to make it work cross-function. And while Java may offer such functionality, there is other functionality it does not offer that could be "added" using macros (eg contracts).
So why is this better than copy & paste? When you copy & paste you make mistakes. (Ever seen someone screw up copy & pasted error handling code? It happens all the time, and error handling code never gets tested. Easy mistake, you forget to update a variable name). Second it allows changes in one central location. Sure, max is never going to change. But my error handling routines might change. And other extensive "language features" I may want to add should be contained in a central location similarly.
Circular thinking. Find the golden tool required to reduce (dramatically) the time and expense to "debug it, redesign it, retest it, certify it, and release it". If you think it can be done, then you may not be the person to do it. I'm not either but problems should be seen as opportunities. How do I open all these cans quickly...
There is no golden tool, or to quote a more famous source (Frederick P Brooks, Jr) there's no silver bullet.
The article discusses the magic tool idea saying the Sustainable Computing Consortium "wants to create automated tools that analyze software and rate its reliability." But the problem with reliability is it's BIG. Not only must your program not crash, not leak resources, not have race conditions, and not degrade in performance over time, but it also needs to be doing the right thing during all of this (you know, what the software was written for in the first place). Finally the software has to be able to do all of this in the face of all the possible failures the system could throw at it. That's no small feat. Now what type of tool will work across the board? I won't stand in the way of someone trying to make one, but honestly I don't see it happening.
There are a lot of different testing techniques that solve different parts of these problems. And each application is going to need it's own unique testing methods in addition to tried and true techniques. But all of this testing is going to take time to develop and/or adapt to the product at hand and finally run. And as you discover reliability bugs you may be blocked before you can find (and fix) more. So it will take a long time to work through the issues.
But your original question is "Why can't there be cutting edge reliability?". And the answer is that there can be, but it has to be what the consumer demands. If the consumer will choose features over reliability that's what the market will deliver. This is simple - if you spend time doing all of this testing and improvement to your product someone else will ship the unreliable product first and everyone will use that. They may curse the developers name while they're using it, but they'll use it. Meanwhile they're improving their product AND getting revenues, and you're just improving your product. They end up having more money to improve their product, and they win.
In cases like NASA the customer demands it, and they get it. A magic tool is a long way off - our code needs a lot more metadata before a magic tool can even begin to tell what's going on.
I don't know about the software raid, but the SX6000 is supported on both Linux & Windows (I haven't used it on Linux though, so YMMV).
There seem to be 2 parts here though: tranferability (is that a word?) and recoverability. There should be no issues w/ recoverability from the same OS (but different installation) - everything's the same.
On transferability there should be no issues with the OS seeing the raw data - the OS isn't the one dealing with the multiple drives, it only sees one. But there is an issue of sharing data between Linux & Windows on a drive. FAT is very good for this, but running FAT on a RAID array is just wrong.
So, last time I had to do this (but w/o a RAID array) I was left w/ ext2 or NTFS. I went with ext2 & a Windows driver that gave native access to the drive. The driver was buggy but going w/ NTFS meant no write access in Linux, and that was unacceptable. So I went with occasionally not being able to access a file from Windows because of the buggy driver.
For a RAID array though ext2 isn't that great either. Imagine waiting for it to fsck! If someone's written an XFS or ReserFS driver for Windows that would solve the transferability problem. But there really may be no good solution here, others might know better.
1) Implement software RAID 5 on all systems ( I still need to back up all data to something to make this work ) and hope no more than one drive fails at a time. This way I wouldn't need to do backups at all. The downside to this would be expandibility. To my knowledge, you cannot easily add storage to an existing RAID set. That means I would need to buy additional storage in sets of 3 HD's and make sure I don't underestimate my storage capacity requirements.
I've gone with the RAID 5 solution and I'm pretty happy with it. I purchased a Promise SX6000 card & 5 80gig hard drives, so my solution was slighly different that what you're proposing.
My experiences have been pretty positive. I end up with ~300gigs of storage (given that I lose one drive, and an 80gig hard drive isn't really 80 gigs). For a while the SX6000 had problems with my 760MXP based motherboard but an update has been released and everything's great.
As for expandibility I'm pushing the limit of my storage right now. My current plan is to move my OS, applications and temporary data off the RAID set and onto their own 120gig hard drive. That should free up 50-60 gigs. After that I'm waiting for 300 gig drives to come out. At that point I'll be able to buy 6 300gig hard drives. I'll take 1 and copy all my data to it. I'll take the other 5 and build a new RAID array (oh, this part takes FOREVER), and then copy the contents of the stand alonge drive on to the array. I shouldn't even need to get a new card. Once the data's successfully transfered I'll take the extra 300 gig drive and hook it up to the RAID array as an available hot swap incase one of the drives dies, that'll give me some extra reliability.
So my general expansion plan is to upgrade when my usable RAID space (4 drives) fits on 1 drive, or about whenever storage space quadruples. That helps to minimize the pain. And if you acquire too much data before that happens figure out a way to fudge it:)
The only concern I have now is that I don't have an offsite backup.
Can you objectively deconstruct them? I don't think you could get any group larger than, say, four people to agree on what, specifically, is wrong with a particular painting or musical piece, or even if it is wrong at all. Art is, by its very nature, a subjective pursuit. Programming produces quantifiable (and hopefully consistent!) results.
People deconstruct art all the time. You are right that people disagree when they do so. Whether it's bad acting or lousy brush work on a painting (or the opposities) there's many ways to do it.
The same thing applies to programs. But iwth programs you have both the code and the whole program. People have different opinions about what is good code and what is bad code. It starts with formatting, and it ends with algorithm choice. People complain about squigly braces on the same line as ifs, and people complain about use of recursion (or lack of it) when they feel it's not appropriate. And there's other things. The other side is what the code produces - the final program. It's easy to complain about objective things (bugs) here, but there are again many subjective elements (user interface design, for example).
So while there are quantifiable aspects (does it do what it says it does?) there are also aspects above and beyond that. And this is where all the art vs science garbage springs up. Anyway, I suspect all scientists will find beauty in their work.
Secondly, we learned at skool (yes some non cool nerds go to school to learn things) certain ways to make your code less likely to be exploitable. For example, making certain objects static is often useful. Object Orientated Programming lends itself to be useful in making secure code.
Assuming you're referring to C/C++ here, and you're talking about local variables, the reason that making them static is 'safer' is because they're no longer declared on the stack. Now if you hand one of those vars off to a misbehaving function a buffer overflow won't go onto the stack (so they wouldn't be able to overwrite your return address for example).
On the other hand you'd be introducing a whole bunch of OTHER problems. It will first make the code non-threadsafe (as all threads will share the same local var). That might not be a big deal. For integers it'd be easy for the inexperienced to leave variables around with previous values. And then of course you may introduce problems similar to strtok where you can only use it on 1 string at a time. So it's certainly not a cure all, and certainly not without it's risks. Finally you can still overflow the buffer, it's just more likely to overflow into a non-dangerous area (where a non-dangerous area is defined as being an area that probably contains all your programs other static variables & global data).
I think the author of the article is right. If you don't need C or C++'s speed you probably shouldn't be using it. Unfortunately there's just so much legacy code.
The problem is you can't keep the numbers senisble because everyone has different standards for their numbers. Therefore you need to not only know the numbers, but you need to know the numbering system used by the developers.
Let's look at each of your points in practice. First, how much has changed. For the Linux kernel 2.2 -> 2.4 was a big upgrade. The version number would imply it's a small upgrade (it's "just a point release"). But RedHat is coming up on version 9, and it's been out for less time than the Linux kernel. So it appears RedHat revs their major release number far more often. Have all of these really been major upgrades? And in the case of Linux, if you go with the traditional "higher is newer and better" than 2.2->2.4 you missed a release, so maybe it's a little more than just a point release. Compare this with Windows where XP is "5.1", and IE is "6.0" in less time. Here IE seems to have advanced at a pretty fast rate (5.5->6.0 added auto-image resize & the image toolbar and some integreation with WMP? Is that a major upgrade?)
Second, what other versions it's likely to be compatible with. The Linux kernel doesn't guarantee binary driver compatability between minor point releases. If you'd expect binary compatibility anywhere, it would be on those smallest of changes. But applications will be binary compatible across a wider range of versions (all major versions? I don't even know, and of course, that's an example of the problem). Windows attemps (obviously it's not perfect) binary compatibility for applications across all versions. Drivers across many versions, but not all.
Finally, how stable it is, this applies only (that I know of) to Linux. And you have to have knowledge that they do this.
Converting version to change/compatibility/stability requires specific knowledge of the developers versioning scheme. Having conventions like saying "Beta" instead of using a bit field in the version are more obvious. Furthermore, having dates gives people an immedite impression of when the bits were released and definitely how old (and potentially out of date) they are.
So, if you follow the software, you'll know the versioning system, but you'd also know these details based on date (or having "Beta" in the name) anyway.
If you didn't follow the software you'd need to look up something, either the versioning system or those 3 details. anyway.
The new MS Office Keyboard from Micrsoft not only includes multimedia and office launching buttons above the function keys but also buttons to the left of the standard buttons dedicated to cut, copy, past, backwards, and forwards. Aside from Undo/redo that accounts for the extra functions you wanted. It even includes an extra large scroll wheel.
I have an office keyboard, and it actually has the undo/redo buttons. They are above the home/end/page up/page down/delete buttons (insert's been moved up above the numeric keypad). But, what it lacks is many multimedia functions. It is, after all, the office keyboard. The only multimedia functions it has is volume controls. Everything else is office related.
It's really unfortunate because the office keyboard is also not a natural keyboard. So it's a choice between a natural keyboard w/ multimedia buttons, or a non-natural keyboard w/o multimedia but with the big scroll wheel & application switching buttons.
I'm tempted to switch back to a natural multimedia keyboard. I just wish I could get the wheel, the multimedia buttons (stop/next/play/etc, in addition to volume) and the natural layout all-in-one.
Tasks which "fork", such as depth-first traversals of complicated structures, aren't simple iterative processes, since there is an implicit "go back" step that rewinds to a previous context where the fork occurs. You can translate these into a loop that lacks recursive function calls, but only if you sprout a data stack to keep track of these forking points. You've really just traded one stack for another and have not transformed the problem.
And of course that was what I was trying to point out. The original author said "it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively." My point was simply that A) It's not that complex and B) It's not just something that beginner programmers do (infact, understanding a stack, and understanding recursion is just using a stack would require a more advance programmer).
I was just trying to point out just because a problem is a "recursive" problem doesn't mean that one needs to solve it using the traditional recursive approach, and in fact, that there are good reasons not to.
And we shouldn't limit ourselves just to creating a data stack. If one uses threaded trees you don't even NEED the stack, it's all stored within your tree already. Therefore one can solve the problem of walking a tree (doing "depth-first traversals of complicated structures") w/o any sort of stack at all.
Take something involving a depth first search of some state space. This is generally an inherently recursive problem.... If one were approaching the problem from another paradigm of programming and using the standard "Learn to Program in One Week" book spaghetti-pseudo, it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively.
Building a non-recursive recursive algorithm is simple. The only structure you need is a stack. It's the *exact* same thing your "resursive" algorithm is doing, the programmer is just being explicit about it.
"Recursing" is as simple as pushing your state object onto the stack. Returning is as simple as popping. When the stack==0 and you return you really return. And guess what? No stack overflow! When you reach the end of your stack, you grow it. One minor bonus is not having to deal with function calls (at the cost of handling your own stack).
Now, that's not to say that for somethings true recursion isn't great. But "gigantic tangles of wild pointers" it doesn't need to be.
Engineers are destined to get fired. Engineers including software engineers typically work on a project, which means that once the project is complete, they don't have to be around. Of course, some people need to be maintaining and debugging, but roughly 90% of engineers can go. I am not just talking about IT, but engineering in general. Let's say you are a construction engineer and designing a building. Once the construction is over, who needs you? We've got to move around and keep finding new projects, and that's the nature of our profession. Sounds kind of like prostitution, but it's not. Prostitutes might have regular customers, but we (real engineers) don't. If you feel OK about it, you'll have lifetime career in IT, if not, you'll find some other job. Simple is that.
This post is just flawed on so many ways, I don't know where to begin.
First, engineers are not destined to get fired. If an engineer worked for Joe Blow who wants a building, sure, they'd end up losing jobs all the time. But they don't just work for Joe Blow.
They work for (or own) construction companies or engineering firms. These companies line up many customers, and the engineers produce a product for their companies customers, just like a software engineer. So when a project is complete, they pick up work on the next one. But they're always working for the same comapny.
Now, if you're designing software internally for a company, then you'll design software to solve a problem, and then the boss will have a new problem to be solved. You'll iterate over problems as long as they exist and the money's flowing - probably forever. You may still be required to do maintenance, but as you point out, it'll require some small percentage of the work previously required freeing up your resources (and your coworkers) to solve other problems.
If you're designing software for a company that sells software then you're just like an engineer. You'll move from product to product. Moving from product to product may just mean moving versions. But new versions are new products. They have new feature lists and can be quite major changes. It's as if a civic engineer reapplies an existing bridge with a few tweaks ("but we want pretty lights on our bridge!"). If you want a software life cycle that matches closely with designing something physical look at game development. Ship a product, write a new one, ship it, write a new one, etc...
Now, if you're a contractor, whether that be in IT or any other field, certainly you're destined to get fired. But not everyone is a contractor. And a software company that only had contractors probably wouldn't last very long.
Now, if you're working for some company, as an employee, that just hired you to solve a one-time problem, then there's something flawed. Really the company should of hired a contractor to do that job. And then the person is an employee of another company, and they have a steady job. (And I realize there's a lot of crappy contracting companies that are more like temp agencies, but there's also contracting companies that are more like an engineering firm. People shouldn't work at the crappy contracting jobs - but hey, I guess it's a job, and the economy sucks).
smells like Object Pascal (Delphi) to me..except with "{" instead of "begin"
That's interesting. I was thinking it smells like C# - except for compiled instead of JITed. The common things being attributes, declaration syntax, & keywords for in/out parameters.
But really I think what I listed, and what you listed, are just some of the many features of modern languages. What I find strange is that there's just so many different modern languages. It just seems like C/C++ have been dominant for so long, and now there's just a large number of modern languages to choose from.
But as far as modern languages go, this certainly seems like a nice enough language. It's good that they have included contract support (given that there's no preprocessor support, which is a good way to do contracts in C/C++).
Unfortunately, given the vast number of modern languages out there, I wonder if this language will ever catch on. Large companies like Sun, Microsoft, and IBM just have so much more money to throw at marketing languages and I don't see them supporting this.
This made me thing of when I went to my dad's office:) but it was the mid 80-late 80s, so stuff was different then. By this time the drive was about 1/2 the size of a refrigerator. But they had these blue cylinders (~1 1/2 ft diameter, ~1/2 high) that you would put in to the drive (I guess it was removable media). He would have to put in some new blue thing in and then my brother and I could play games on the Wang terminals.
That's is exactly why good developers prefer verbose logging instead of debugging.
If verbose logging is applied in a smart way, errors will show up in such a way you will be able to see where and why the code fails. Then it's up to the developer to find out if either te predicates are wrong or the context to which they apply fails... (emphasis added)
That's ridiculous! I'd say that good developers use both. And they also use assertions.
Logging gives you a picture of your program over time. It's a great tool and can help find bugs that are otherwise difficult. You can watch states change, and see method calls, from your hand picked logging statements.
On the other hand a debugger gives you an instant snapshot of your program, and allows you to inspect the state in detail. Again, another great tool.
Logging's greatest weakness is it requires an edit-compile cycle to get new messages in. And it's real easy to end up not having messages in the right spots or not displaying enough information (or the right information).
Whereas with a debugger you can load the program up, set a break point, run, and then step through and see what's happening. No edit, no compile, you're just there. But it's greatest weakness is watching the program state change over a long time.
So they're both great tools and are good for different things. Good programmers know how to use the tools that are available to them.
Speeding up shell sort is not very exciting and hardly useful. It's the slowest of the n^2 sorts [wku.edu]. I'm surprised no one has pointed this out. Where are the computer geeks?
Quoting from your own link: "Invented by Donald Shell in 1959, the shell sort is the most efficient of the O(n2) class of sorting algorithms. Of course, the shell sort is also the most complex of the O(n2) algorithms."
Which part of "shell sort is the most efficient of the O(n2) class of sorting algorithms" do you not understand?
Of course, why speed up an O(n2) sort - why not try to speed up an O(n log n) sort like quicksort? try and figure out the best way to choose the pivot point!
Try to explain: (int * ac, char ** av) in 100 words or less!
av is an array of strings which holds your arguments. ac is the count of arguments passed to the program. av[0] is the program name that was ran. av[1] is the first argument.
Do I win a prize?
Anyway, ac shouldn't be a pointer to an int - it should be an int, eg: int main(int ac, char **argv)
The native CD burning is overrated. Most users need.iso support and such from Nero (et al) anyway. Also, since XP can do.zip files but not.rar files, XP still needs WinRAR loaded.
On the ISO front there's a free power toy (not written by MS) that allows you to create / record ISOs.
I actually had a Debian ISO I had downloaded onto my XP box and needed to burn. For some reason the *real* CD burning software I had wasn't working. This little power toy let me burn the CD and saved the day.
The CD burning support exposes a bunch of APIs that others can use to accomplish this. I wonder if the ZIP support does the same thing (so that RAR support could be added).
You're right, in your sarcasm at least. You can't get rid of all those jobs and expect it to work. One parent post mentioned that if you lose ten million entry level jobs, you may get back ten thousand non-entry level jobs. I disagree with even that bleak outlook. Try telling me that a retail cashier is going to lose his job, turn around, and get hired developing RFID technology.
All it will do, in my opinion, is lower the standard of entry-level. Those with cushy, high-paying tech jobs will be paid less as a massive shift in the job markey occurs. Ten million people jobless is a huge part of the population to have lose jobs. It may be small compared to 250 million, but our economy is a delicate balance and this would upset it. I'm thinking recession, possibly even a minor depression.
The economy can deal with the changes due to technology. First, it's not like retailers are going to switch over in one day, all of them on the same day, and poof, we have millions of unemployed clerks. So it's not going to be an overnight we're in a recession sort of thing.
What would be likely to happen is that a slow shift occurs laying off small amounts of people over a long period of time. As people are laid off they need to learn a new skill and do that instead. The really smart people are probably learning a new skill today before they get laid off. This has happened in the past and it'll certainly continue to happen. Think of cars. There certainly used to be more human labor than involved today.
This is good for consumers though. As a customer of stores that converted we'll start seeing lower prices. Then I'll have more money to spend. And I'll probably end up spending some of that money going towards a job held by someone who used to be a cashier. Now I'm getting groceries and some new stuff instead of just groceries for the same amount of money. Incidentially the cashier with a new job is also paying less for groceries and is probably better off in the long run too.
In the end, it boils down to the haves and have-nots. It will just widen the gap between the two. Capitalism is like Communism: it looks great on paper, but hurts in practice. Too many "little guys" get hurt while the upper class has more money than they know what to do with.
In communism you'd have continued inefficiency because "we have to have jobs for these people." and therefore no progress. It's easy for either system to screw over both small and large amounts of people. But capitalism certainly puts the pressure on to progress.
The DOJ sold out on this settlement with Microsoft. I have no doubts that a Gore administration would have done just the same, but Charles James really screwed up on this one.
The interesting thing here is that the Clinton administration was willing to settle too, it's been the states holding out all along.
The book "World War 3.0" by Ken Auletta gets into the settlement proceedings when Jackson was ruling. Ken Auletta is one of the reporters that Jackson talked the most too, so it's got an interesting perspective.
The cost of software, in the grand scheme of most operations, is absolutely trivial.
Infact, not only is the cost of software trivial, but software generally increases profits. Hardware does the same thing. There's this little thing called 'productivity', and software & hardware increase it. If it didn't, companies wouldn't buy it. End of story.
uber-parent: For two generations at least the music industry has been selling rebellion.... They have been in a small way part of what has made North american society what it is.Rebellious, indifferent -- hostile towards authority.
parent: Mod parent up, , maybe +3/4 (insightful?)
Come on! America is not rebellious because of the music industry, the music industry is selling rebellion because that's what America is. There's this little war we fought with another country you may have heard of called Great Britain. America was born in rebellion.
Slashdot Mirror
NT based Windows is primarily unstable when in low memory or low diskspace conditions, which may happen if you're running too many apps. I've found that Windows and Windows apps usually handle these situations poorly - especially with disk space, where the errors sometimes are meaningless or confusing.
You can't just blame Windows here - Windows allows apps reliable control of their memory space like just about any other modern OS (But not Linux - it will pick a process & kill it when it runs out of memory rather than failing allocations).
The fact of the matter is writing code that can handle running Out Of Memory (OOM) is very hard to get right. Consequentially if you haven't tested your program to handle OOM it most likely doesn't. The more memory allocation you do the more likely this is true. Great example: developer ASSERTs an allocation succeeds (but that's gone in the retail build). Hit a NULL reference exception, app goes poof.
Finally it's really hard to test for, so most people probably don't do it. Chalk it up to another reason software sucks and still crashes: people don't test for these "corner cases" (hah, tell that to the person writing their paper who doesn't know how to save). And it's certainly worse that an OS would consider it acceptable to take away the chance to operate correctly from the developer.
It's not Google's fault that it doesn't index these. The first one has the following robots.txt:
/offline.html /search/results.asp /browse/currentreports/ /browse/currentreports /inst/gateway.asp /imedia/
/*.pdf$ /imedia/
User-agent: *
Disallow:
Disallow:
Disallow:
Disallow:
Disallow:
Disallow:
User-Agent: Googlebot
Disallow:
Disallow:
And as far as the second one goes I couldn't even find how to get to the journals without a user account. If people want to see Google index these they'll need to talk to the web site authors who choose to prevent Google from doing so.
Shadow government, controllers, bad guys with a worse agenda, at high order giving levels where the over-all picture can be kept from the lower level workers.
There's so much of that stuff now that you can't keep up with it. People are quick to dismiss it as "conspiracy theory".
And how do we know YOU'RE not part of the conspiracy? Maybe you're just a worker spouting disinformation so we don't discover the TRUTH? Maybe you're working for multiple governments, loyal to no one but yourself, spouting disinformation to all! Or maybe not.
Wow, you said a lot, and didn't really describe anything very well.
First you're blending inlining and macros. Beginning with "Inlining works like this" and ending with "since inlining doesn't work anyway" you're talking about macros. Your next paragraph talks about inlining - in that a JIT can perform this optimization. But nearly all compilers perform this simple optimization all the time, including a JIT, because it's also a compiler.
So, now that we all know that inlining is moving functions inline within other functions, either by programmer or compiler, we can move onto macros, which the bulk of your post discusses. The idea that "today's cut and paste GUI IDEs" can replace macros is insane. Macros provide a feature that functions cannot. While your trivial examples (and your quote was originally about C, yet your code is not C) don't demonstrate this at all. A more common example would be "#define max(a,b) ((a)>(b))?(a):(b)"
This is an extremely typical use of a macro. And it's bad & wrong. A function would be much better here, would be inlined by the compiler (in either Java or a traditional compiler), and wouldn't have problems when you did "foo = max(x++,y++);" where you end up doing an accidental double increment.
So, a little off topic, but macros do provide functionality that is not otherwise available. As one of your snippets begins to show it allows you to redefine the language. For example, let's say I want to add exception handling to C. I make a few macros:
#define TRY { int error = 0; {
#define CATCH } {\
catchlabel:
#define ENDCATCH } }
#define THROW(errNo) error = errNo; goto catchlabel;
Sure, it's primitive, but I also spent 5 minutes typing it into a little tiny window on Slashdot, so what do you expect? If you work with it you can do more. You could get crazy & start using setjmp & longjmp for your error handling needs to make it work cross-function. And while Java may offer such functionality, there is other functionality it does not offer that could be "added" using macros (eg contracts).
So why is this better than copy & paste? When you copy & paste you make mistakes. (Ever seen someone screw up copy & pasted error handling code? It happens all the time, and error handling code never gets tested. Easy mistake, you forget to update a variable name). Second it allows changes in one central location. Sure, max is never going to change. But my error handling routines might change. And other extensive "language features" I may want to add should be contained in a central location similarly.
Circular thinking. Find the golden tool required to reduce (dramatically) the time and expense to "debug it, redesign it, retest it, certify it, and release it". If you think it can be done, then you may not be the person to do it. I'm not either but problems should be seen as opportunities. How do I open all these cans quickly...
There is no golden tool, or to quote a more famous source (Frederick P Brooks, Jr) there's no silver bullet.
The article discusses the magic tool idea saying the Sustainable Computing Consortium "wants to create automated tools that analyze software and rate its reliability." But the problem with reliability is it's BIG. Not only must your program not crash, not leak resources, not have race conditions, and not degrade in performance over time, but it also needs to be doing the right thing during all of this (you know, what the software was written for in the first place). Finally the software has to be able to do all of this in the face of all the possible failures the system could throw at it. That's no small feat. Now what type of tool will work across the board? I won't stand in the way of someone trying to make one, but honestly I don't see it happening.
There are a lot of different testing techniques that solve different parts of these problems. And each application is going to need it's own unique testing methods in addition to tried and true techniques. But all of this testing is going to take time to develop and/or adapt to the product at hand and finally run. And as you discover reliability bugs you may be blocked before you can find (and fix) more. So it will take a long time to work through the issues.
But your original question is "Why can't there be cutting edge reliability?". And the answer is that there can be, but it has to be what the consumer demands. If the consumer will choose features over reliability that's what the market will deliver. This is simple - if you spend time doing all of this testing and improvement to your product someone else will ship the unreliable product first and everyone will use that. They may curse the developers name while they're using it, but they'll use it. Meanwhile they're improving their product AND getting revenues, and you're just improving your product. They end up having more money to improve their product, and they win.
In cases like NASA the customer demands it, and they get it. A magic tool is a long way off - our code needs a lot more metadata before a magic tool can even begin to tell what's going on.
I don't know about the software raid, but the SX6000 is supported on both Linux & Windows (I haven't used it on Linux though, so YMMV).
There seem to be 2 parts here though: tranferability (is that a word?) and recoverability. There should be no issues w/ recoverability from the same OS (but different installation) - everything's the same.
On transferability there should be no issues with the OS seeing the raw data - the OS isn't the one dealing with the multiple drives, it only sees one. But there is an issue of sharing data between Linux & Windows on a drive. FAT is very good for this, but running FAT on a RAID array is just wrong.
So, last time I had to do this (but w/o a RAID array) I was left w/ ext2 or NTFS. I went with ext2 & a Windows driver that gave native access to the drive. The driver was buggy but going w/ NTFS meant no write access in Linux, and that was unacceptable. So I went with occasionally not being able to access a file from Windows because of the buggy driver.
For a RAID array though ext2 isn't that great either. Imagine waiting for it to fsck! If someone's written an XFS or ReserFS driver for Windows that would solve the transferability problem. But there really may be no good solution here, others might know better.
1) Implement software RAID 5 on all systems ( I still need to back up all data to something to make this work ) and hope no more than one drive fails at a time. This way I wouldn't need to do backups at all. The downside to this would be expandibility. To my knowledge, you cannot easily add storage to an existing RAID set. That means I would need to buy additional storage in sets of 3 HD's and make sure I don't underestimate my storage capacity requirements.
:)
I've gone with the RAID 5 solution and I'm pretty happy with it. I purchased a Promise SX6000 card & 5 80gig hard drives, so my solution was slighly different that what you're proposing.
My experiences have been pretty positive. I end up with ~300gigs of storage (given that I lose one drive, and an 80gig hard drive isn't really 80 gigs). For a while the SX6000 had problems with my 760MXP based motherboard but an update has been released and everything's great.
As for expandibility I'm pushing the limit of my storage right now. My current plan is to move my OS, applications and temporary data off the RAID set and onto their own 120gig hard drive. That should free up 50-60 gigs. After that I'm waiting for 300 gig drives to come out. At that point I'll be able to buy 6 300gig hard drives. I'll take 1 and copy all my data to it. I'll take the other 5 and build a new RAID array (oh, this part takes FOREVER), and then copy the contents of the stand alonge drive on to the array. I shouldn't even need to get a new card. Once the data's successfully transfered I'll take the extra 300 gig drive and hook it up to the RAID array as an available hot swap incase one of the drives dies, that'll give me some extra reliability.
So my general expansion plan is to upgrade when my usable RAID space (4 drives) fits on 1 drive, or about whenever storage space quadruples. That helps to minimize the pain. And if you acquire too much data before that happens figure out a way to fudge it
The only concern I have now is that I don't have an offsite backup.
Can you objectively deconstruct them? I don't think you could get any group larger than, say, four people to agree on what, specifically, is wrong with a particular painting or musical piece, or even if it is wrong at all. Art is, by its very nature, a subjective pursuit. Programming produces quantifiable (and hopefully consistent!) results.
People deconstruct art all the time. You are right that people disagree when they do so. Whether it's bad acting or lousy brush work on a painting (or the opposities) there's many ways to do it.
The same thing applies to programs. But iwth programs you have both the code and the whole program. People have different opinions about what is good code and what is bad code. It starts with formatting, and it ends with algorithm choice. People complain about squigly braces on the same line as ifs, and people complain about use of recursion (or lack of it) when they feel it's not appropriate. And there's other things. The other side is what the code produces - the final program. It's easy to complain about objective things (bugs) here, but there are again many subjective elements (user interface design, for example).
So while there are quantifiable aspects (does it do what it says it does?) there are also aspects above and beyond that. And this is where all the art vs science garbage springs up. Anyway, I suspect all scientists will find beauty in their work.
Secondly, we learned at skool (yes some non cool nerds go to school to learn things) certain ways to make your code less likely to be exploitable. For example, making certain objects static is often useful. Object Orientated Programming lends itself to be useful in making secure code.
Assuming you're referring to C/C++ here, and you're talking about local variables, the reason that making them static is 'safer' is because they're no longer declared on the stack. Now if you hand one of those vars off to a misbehaving function a buffer overflow won't go onto the stack (so they wouldn't be able to overwrite your return address for example).
On the other hand you'd be introducing a whole bunch of OTHER problems. It will first make the code non-threadsafe (as all threads will share the same local var). That might not be a big deal. For integers it'd be easy for the inexperienced to leave variables around with previous values. And then of course you may introduce problems similar to strtok where you can only use it on 1 string at a time. So it's certainly not a cure all, and certainly not without it's risks. Finally you can still overflow the buffer, it's just more likely to overflow into a non-dangerous area (where a non-dangerous area is defined as being an area that probably contains all your programs other static variables & global data).
I think the author of the article is right. If you don't need C or C++'s speed you probably shouldn't be using it. Unfortunately there's just so much legacy code.
The problem is you can't keep the numbers senisble because everyone has different standards for their numbers. Therefore you need to not only know the numbers, but you need to know the numbering system used by the developers.
Let's look at each of your points in practice. First, how much has changed. For the Linux kernel 2.2 -> 2.4 was a big upgrade. The version number would imply it's a small upgrade (it's "just a point release"). But RedHat is coming up on version 9, and it's been out for less time than the Linux kernel. So it appears RedHat revs their major release number far more often. Have all of these really been major upgrades? And in the case of Linux, if you go with the traditional "higher is newer and better" than 2.2->2.4 you missed a release, so maybe it's a little more than just a point release. Compare this with Windows where XP is "5.1", and IE is "6.0" in less time. Here IE seems to have advanced at a pretty fast rate (5.5->6.0 added auto-image resize & the image toolbar and some integreation with WMP? Is that a major upgrade?)
Second, what other versions it's likely to be compatible with. The Linux kernel doesn't guarantee binary driver compatability between minor point releases. If you'd expect binary compatibility anywhere, it would be on those smallest of changes. But applications will be binary compatible across a wider range of versions (all major versions? I don't even know, and of course, that's an example of the problem). Windows attemps (obviously it's not perfect) binary compatibility for applications across all versions. Drivers across many versions, but not all.
Finally, how stable it is, this applies only (that I know of) to Linux. And you have to have knowledge that they do this.
Converting version to change/compatibility/stability requires specific knowledge of the developers versioning scheme. Having conventions like saying "Beta" instead of using a bit field in the version are more obvious. Furthermore, having dates gives people an immedite impression of when the bits were released and definitely how old (and potentially out of date) they are.
So, if you follow the software, you'll know the versioning system, but you'd also know these details based on date (or having "Beta" in the name) anyway.
If you didn't follow the software you'd need to look up something, either the versioning system or those 3 details. anyway.
The new MS Office Keyboard from Micrsoft not only includes multimedia and office launching buttons above the function keys but also buttons to the left of the standard buttons dedicated to cut, copy, past, backwards, and forwards. Aside from Undo/redo that accounts for the extra functions you wanted. It even includes an extra large scroll wheel.
I have an office keyboard, and it actually has the undo/redo buttons. They are above the home/end/page up/page down/delete buttons (insert's been moved up above the numeric keypad). But, what it lacks is many multimedia functions. It is, after all, the office keyboard. The only multimedia functions it has is volume controls. Everything else is office related.
It's really unfortunate because the office keyboard is also not a natural keyboard. So it's a choice between a natural keyboard w/ multimedia buttons, or a non-natural keyboard w/o multimedia but with the big scroll wheel & application switching buttons.
I'm tempted to switch back to a natural multimedia keyboard. I just wish I could get the wheel, the multimedia buttons (stop/next/play/etc, in addition to volume) and the natural layout all-in-one.
Tasks which "fork", such as depth-first traversals of complicated structures, aren't simple iterative processes, since there is an implicit "go back" step that rewinds to a previous context where the fork occurs. You can translate these into a loop that lacks recursive function calls, but only if you sprout a data stack to keep track of these forking points. You've really just traded one stack for another and have not transformed the problem.
And of course that was what I was trying to point out. The original author said "it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively." My point was simply that A) It's not that complex and B) It's not just something that beginner programmers do (infact, understanding a stack, and understanding recursion is just using a stack would require a more advance programmer).
I was just trying to point out just because a problem is a "recursive" problem doesn't mean that one needs to solve it using the traditional recursive approach, and in fact, that there are good reasons not to.
And we shouldn't limit ourselves just to creating a data stack. If one uses threaded trees you don't even NEED the stack, it's all stored within your tree already. Therefore one can solve the problem of walking a tree (doing "depth-first traversals of complicated structures") w/o any sort of stack at all.
Take something involving a depth first search of some state space. This is generally an inherently recursive problem. ... If one were approaching the problem from another paradigm of programming and using the standard "Learn to Program in One Week" book spaghetti-pseudo, it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively.
Building a non-recursive recursive algorithm is simple. The only structure you need is a stack. It's the *exact* same thing your "resursive" algorithm is doing, the programmer is just being explicit about it.
"Recursing" is as simple as pushing your state object onto the stack. Returning is as simple as popping. When the stack==0 and you return you really return. And guess what? No stack overflow! When you reach the end of your stack, you grow it. One minor bonus is not having to deal with function calls (at the cost of handling your own stack).
Now, that's not to say that for somethings true recursion isn't great. But "gigantic tangles of wild pointers" it doesn't need to be.
Engineers are destined to get fired. Engineers including software engineers typically work on a project, which means that once the project is complete, they don't have to be around. Of course, some people need to be maintaining and debugging, but roughly 90% of engineers can go. I am not just talking about IT, but engineering in general. Let's say you are a construction engineer and designing a building. Once the construction is over, who needs you? We've got to move around and keep finding new projects, and that's the nature of our profession. Sounds kind of like prostitution, but it's not. Prostitutes might have regular customers, but we (real engineers) don't. If you feel OK about it, you'll have lifetime career in IT, if not, you'll find some other job. Simple is that.
This post is just flawed on so many ways, I don't know where to begin.
First, engineers are not destined to get fired. If an engineer worked for Joe Blow who wants a building, sure, they'd end up losing jobs all the time. But they don't just work for Joe Blow.
They work for (or own) construction companies or engineering firms. These companies line up many customers, and the engineers produce a product for their companies customers, just like a software engineer. So when a project is complete, they pick up work on the next one. But they're always working for the same comapny.
Now, if you're designing software internally for a company, then you'll design software to solve a problem, and then the boss will have a new problem to be solved. You'll iterate over problems as long as they exist and the money's flowing - probably forever. You may still be required to do maintenance, but as you point out, it'll require some small percentage of the work previously required freeing up your resources (and your coworkers) to solve other problems.
If you're designing software for a company that sells software then you're just like an engineer. You'll move from product to product. Moving from product to product may just mean moving versions. But new versions are new products. They have new feature lists and can be quite major changes. It's as if a civic engineer reapplies an existing bridge with a few tweaks ("but we want pretty lights on our bridge!"). If you want a software life cycle that matches closely with designing something physical look at game development. Ship a product, write a new one, ship it, write a new one, etc...
Now, if you're a contractor, whether that be in IT or any other field, certainly you're destined to get fired. But not everyone is a contractor. And a software company that only had contractors probably wouldn't last very long.
Now, if you're working for some company, as an employee, that just hired you to solve a one-time problem, then there's something flawed. Really the company should of hired a contractor to do that job. And then the person is an employee of another company, and they have a steady job. (And I realize there's a lot of crappy contracting companies that are more like temp agencies, but there's also contracting companies that are more like an engineering firm. People shouldn't work at the crappy contracting jobs - but hey, I guess it's a job, and the economy sucks).
smells like Object Pascal (Delphi) to me..except with "{" instead of "begin"
That's interesting. I was thinking it smells like C# - except for compiled instead of JITed. The common things being attributes, declaration syntax, & keywords for in/out parameters.
But really I think what I listed, and what you listed, are just some of the many features of modern languages. What I find strange is that there's just so many different modern languages. It just seems like C/C++ have been dominant for so long, and now there's just a large number of modern languages to choose from.
But as far as modern languages go, this certainly seems like a nice enough language. It's good that they have included contract support (given that there's no preprocessor support, which is a good way to do contracts in C/C++).
Unfortunately, given the vast number of modern languages out there, I wonder if this language will ever catch on. Large companies like Sun, Microsoft, and IBM just have so much more money to throw at marketing languages and I don't see them supporting this.
This made me thing of when I went to my dad's office :) but it was the mid 80-late 80s, so stuff was different then. By this time the drive was about 1/2 the size of a refrigerator. But they had these blue cylinders (~1 1/2 ft diameter, ~1/2 high) that you would put in to the drive (I guess it was removable media). He would have to put in some new blue thing in and then my brother and I could play games on the Wang terminals.
That's is exactly why good developers prefer verbose logging instead of debugging.
If verbose logging is applied in a smart way, errors will show up in such a way you will be able to see where and why the code fails. Then it's up to the developer to find out if either te predicates are wrong or the context to which they apply fails... (emphasis added)
That's ridiculous! I'd say that good developers use both. And they also use assertions.
Logging gives you a picture of your program over time. It's a great tool and can help find bugs that are otherwise difficult. You can watch states change, and see method calls, from your hand picked logging statements.
On the other hand a debugger gives you an instant snapshot of your program, and allows you to inspect the state in detail. Again, another great tool.
Logging's greatest weakness is it requires an edit-compile cycle to get new messages in. And it's real easy to end up not having messages in the right spots or not displaying enough information (or the right information).
Whereas with a debugger you can load the program up, set a break point, run, and then step through and see what's happening. No edit, no compile, you're just there. But it's greatest weakness is watching the program state change over a long time.
So they're both great tools and are good for different things. Good programmers know how to use the tools that are available to them.
Speeding up shell sort is not very exciting and hardly useful. It's the slowest of the n^2 sorts [wku.edu]. I'm surprised no one has pointed this out. Where are the computer geeks?
Quoting from your own link: "Invented by Donald Shell in 1959, the shell sort is the most efficient of the O(n2) class of sorting algorithms. Of course, the shell sort is also the most complex of the O(n2) algorithms."
Which part of "shell sort is the most efficient of the O(n2) class of sorting algorithms" do you not understand?
Of course, why speed up an O(n2) sort - why not try to speed up an O(n log n) sort like quicksort? try and figure out the best way to choose the pivot point!
Nothing rhymes with it, and that makes it hard for a rapper like me to rap about it.
Try "door hinge", it almost works.
Try to explain: (int * ac, char ** av) in 100 words or less!
av is an array of strings which holds your arguments. ac is the count of arguments passed to the
program. av[0] is the program name that was ran. av[1] is the first argument.
Do I win a prize?
Anyway, ac shouldn't be a pointer to an int - it should be an int, eg: int main(int ac, char **argv)
The native CD burning is overrated. Most users need .iso support and such from Nero (et al) anyway. Also, since XP can do .zip files but not .rar files, XP still needs WinRAR loaded.
On the ISO front there's a free power toy (not written by MS) that allows you to create / record ISOs.
I actually had a Debian ISO I had downloaded onto my XP box and needed to burn. For some reason the *real* CD burning software I had wasn't working. This little power toy let me burn the CD and saved the day.
The CD burning support exposes a bunch of APIs that others can use to accomplish this. I wonder if the ZIP support does the same thing (so that RAR support could be added).
You're right, in your sarcasm at least. You can't get rid of all those jobs and expect it to work. One parent post mentioned that if you lose ten million entry level jobs, you may get back ten thousand non-entry level jobs. I disagree with even that bleak outlook. Try telling me that a retail cashier is going to lose his job, turn around, and get hired developing RFID technology.
All it will do, in my opinion, is lower the standard of entry-level. Those with cushy, high-paying tech jobs will be paid less as a massive shift in the job markey occurs. Ten million people jobless is a huge part of the population to have lose jobs. It may be small compared to 250 million, but our economy is a delicate balance and this would upset it. I'm thinking recession, possibly even a minor depression.
The economy can deal with the changes due to technology. First, it's not like retailers are going to switch over in one day, all of them on the same day, and poof, we have millions of unemployed clerks. So it's not going to be an overnight we're in a recession sort of thing.
What would be likely to happen is that a slow shift occurs laying off small amounts of people over a long period of time. As people are laid off they need to learn a new skill and do that instead. The really smart people are probably learning a new skill today before they get laid off. This has happened in the past and it'll certainly continue to happen. Think of cars. There certainly used to be more human labor than involved today.
This is good for consumers though. As a customer of stores that converted we'll start seeing lower prices. Then I'll have more money to spend. And I'll probably end up spending some of that money going towards a job held by someone who used to be a cashier. Now I'm getting groceries and some new stuff instead of just groceries for the same amount of money. Incidentially the cashier with a new job is also paying less for groceries and is probably better off in the long run too.
In the end, it boils down to the haves and have-nots. It will just widen the gap between the two. Capitalism is like Communism: it looks great on paper, but hurts in practice. Too many "little guys" get hurt while the upper class has more money than they know what to do with.
In communism you'd have continued inefficiency because "we have to have jobs for these people." and therefore no progress. It's easy for either system to screw over both small and large amounts of people. But capitalism certainly puts the pressure on to progress.
The DOJ sold out on this settlement with Microsoft. I have no doubts that a Gore administration would have done just the same, but Charles James really screwed up on this one.
The interesting thing here is that the Clinton administration was willing to settle too, it's been the states holding out all along.
The book "World War 3.0" by Ken Auletta gets into the settlement proceedings when Jackson was ruling. Ken Auletta is one of the reporters that Jackson talked the most too, so it's got an interesting perspective.
The cost of software, in the grand scheme of most operations, is absolutely trivial.
Infact, not only is the cost of software trivial, but software generally increases profits. Hardware does the same thing. There's this little thing called 'productivity', and software & hardware increase it. If it didn't, companies wouldn't buy it. End of story.
uber-parent: For two generations at least the music industry has been selling rebellion. ... They have been in a small way part of what has made North american society what it is.Rebellious, indifferent -- hostile towards authority.
parent: Mod parent up, , maybe +3/4 (insightful?)
Come on! America is not rebellious because of the music industry, the music industry is selling rebellion because that's what America is. There's this little war we fought with another country you may have heard of called Great Britain. America was born in rebellion.