Remember when Oprah got sued by the beef industry for expressing her concerns about the safety of meat? Better watch what you say in public about the products you use. Unless it's gushing, fan-boy enthusiasm, you could have the "product libel" lawyers all over you. So, yes, it's safer to just shut up; don't make any waves. It's one of the small prices we have to pay for freedom in this country.
Actually there is a big difference there between Oprah and some Joe Smoe saying something. Oprah is a public person, and one that carries weight in what she says. (Even if she really shouldn't.) As such, she can be found libel when saying something like that.
However, for someone that is not a public person it is harder to show that they would carry weight in what they say, thus they would not be libel.
Now, if an executive of a competitor said something, then they would be under the same rules as Oprah.
At least in the US, the law does give weight to (a) how public a person is, and (b) how much weight a persons word carries. Additionally, a person cannot be found libel if what they said is indeed true. Libel only applies if the statement is false or (possibly) extremely misleading.
This is also why you generally do not find competitors explicitly bashing each other. For example, this is why Apple uses the name "Mac" and "PC" in their commercials, even when it is obvious that they are meaning "Mac" and "Windows".
Something like 70% of Americans do demand a change in government.
Where's your data for that? From a skewed poll? Likely because that is flat-out wrong. The majority may be unhappy, but unhappy does not equal impeach.
Of course, the networks overwhelmingly favor commentators who are of the right or center.
Another major fallacy. Only a few networks even have commentators that even discuss both sides of an issue. Those that do not discuss both sides tend to be very much on the far left - no where near center, let alone the right. (Yes, that's ABC, CBS, NBC, MSNBC, CNN, NY Times, Washington Post, Wall Street Journal, USA Today, and pretty much all other major news outlets in the US. Fox News is the only one I'm aware of that even discusses both sides.)
So they have already decided to allow a 15-year grace period and no interest. Given the time-value of money, I'm guessing that even as-is, IBM has de facto given them the computers at below cost. They've no doubt lost money on the deal, and have been extremely generous already.
Very true - according to the Fed's Inflation Calculator, the $5M owed in 1992 (15 years ago) would be equivalent to $7,410,869.57. That's nearly 150% of the original amount ($7.5M would be 150% even.) So that's quite a bargain. And that's just to get them even. Usually loans are charged as inflation plus so that it is more than merely being even.
So, for the $5M in 2007 dollars (using the same inflation calculator), IBM is really getting $3,373,423.29 1992 dollars - a savings for the district of $1,626,576.71 1992 dollars.
To be really accurate you'd have to wait until each of the years in the contract passed to calculate how much IBM really lost out. It's likely a few hundred grand more than the above calculations. We just can't know until we can compute the difference by inflation, which could probably be approximated at about 1.5% to 3% per year going forward.
Who was it who said, "People always 'discover' Higgs particles when funding is low."
So then - theoretically at least - we must keep the funding low to get to keep getting lots of cool discoveries. Just think about it - give every scientist a penny budget and they should then be able to 'discover' something; just think of the 100's of millions of discoveries we could get out of a million dollars that way...
By scientific consensus, we believed the Earth was flat, until we were told it wasn't. We attacked the naysayers and tried to have them killed...
The ones behing killing people were upholding a religious consensus--even the ancient Greeks knew the world was round.
not quite correct - they were the rulers of the day, though their advisers were the sort too. In other words, the Average Joe could careless - it was those at the top of the political chain - and only in the European/Wester World at that - who were threated by the thought of "being wrong" that were doing this. Any Average Joe participating was primarily due to the law from rulers. But as the GP pointed out, this was a scientific consensus - the scientists were advising the rulers as well as the religious folks.
It was more that none of them (scientists, religious folks, and the rulers) wanted to be wrong and anyone who said otherwise was put to death. This is perhaps the primary issue - and one that goes with most monarchy governments, as well as any other kind of government where a single person or small ruling class are in charge: say the ruling class is wrong, and risk your life. It has nothing, really, to do with religion.
This often gets confused as a religious consensus because the ruling class (e.g. the monarchy's) also set forth the religious practices and beliefs. However, the two are otherwise not really that much connected - it was about equally scientific pushed, and was held by the scientific community at that time quite strongly.
For starters, the only real gadgets I have is my cell phone and a few computers. I got a couple other things the are work related, but don't do anything really (not a crackberry, pda, etc.). However, while a true nerd/geek - I could just as easily drop all the gadgets and computers and go do something else with my life - write books, play music, etc. There's not a thing technology has that I really need. (And by technology, I am referring to computer related stuff.) Advances in medicine, etc. are great and useful, and my wife certainly needs them (asthma).
If my bank weren't 600 miles away (no local branches, and I don't want to change banks either), then I could do without a credit/debit card too. Of course, I could do that and just use a checkbook too, not a problem; though I'd much prefer going to cash. (I also have a book on managing money; and the author found that by going to only using cash one would spend roughly 34% less money than by other means - namely credit/debit cards.)
Now, of course you could get picky about what you want to call a gadget. And if you really wanted to do so, then you'd pretty much have to consider most vehicles gadgets these days too, and with that respect - while I'd prefer to keep my car due to family being spread out across a few states, I could otherwise go without it without much problem. It'd take me a little longer (at present) to get to work - 20 minutes instead of 10 - but would be well worth it.
So I guess the real question is - what does this "first world" lifestyle really have to offer that is needed? Well, not much really. Most of what is really needed is provided simply by the sanitization and quality levels (e.g. food, drugs, etc.). Most anything else we could do without quite easily. Sure, it won't be the same, but we'd probably all enjoy life a lot more.
And, fyi, I am not joking by the above. I quite often go without touching a computer for a few days; I have gone months without a TV; I can even easily go a few days without using my cell phone. My current line of work is what keeps me on a computer and the Internet most of the time, but if I changed that I could easily fall off-grid and not even realize it.
This is the real reason why the FCC and Congress are pushing for HDTV. They see the Billions of dollars that it could bring in in profit. A newspaper article I came across back in the late 90's, when HDTV was suppose to go live and SDTV was suppose to be shutoff in 2001, had an estimate of $4.2 Billion USD that the SDTV spectrum would go for at that time. It's probably a lot higher now.
So, to MPAA, RIAA, NASCAR, NFL, NBA, ABL, NHL, etc. all want HDTV so they can control what you can watch, how you watch it, what you watch it on, etc; and the US Gov't wants HDTV so they can make billions of dollars in pure profit.
I'm not saying that we couldn't use the SDTV more effectively (or even AM/FM frequencies for that matter); but this is not something that is in the consumer/customer's interest. It's all $$ motivated.
I am have been wondering if that is due to supposed improved safety. Did the rise in SUV require cars too be more sturdy for crash tests? Or is the increased mass a natural design for increased crash safety for passengers?
That may be part of it, but is not the whole of it. I think there are other things going on too. Though, other things required for emissions, etc. also add weight and destroy fuel efficiency too. Couple examples: additives in the fuel and ethanol.
Btw, in my vehicles, I have seen ethanol halve the MPG with no other change.
The current huge gas tanks don't seem to help the situation either. A 10 gallon tank was pretty good size for a passenger car back in the 70s and 80s, 14 gallon tank seemd average in 2001, but now it seems the average is up to 16 gallons.
Do car cruising ranges somehow figure in CAFE fleet calculations?
I don't know what goes into the CAFE fleet calculations; however, it seems to me from several different vehicles that they seem to set the size of the tank based on a common mileage per tank figure of about 400 miles per tank (full to dry empty). My 2005 Mazda3 with a 14 gallon tank, my previous 1994 Grand Marquis with a 20 gallon tank (the Mazda3 replaced it), my wife's Infiniti J30 with a ~20 gallon tank, and several other vehicles I have observed all get about 400 miles per tank, though their miles per gallon varies widely. I don't know why it is 400 miles per tank, but that seems to be a commonality between the vehicles. (This is based on the fact that they all seem to get about 100 miles per quarter tank; though I did push the Grand Marquis to nearly 400 miles on a tank once - then I put in 19.76 gallons; I was within 5 or 10 miles of the 400 mile mark on the trip odometer.)
I know my new 2005 Mazda3 gets between 26 MPG city and 32 MPG highway, and my parent's old 1987 Omni got something like 29 city/35 highway - and at times as high as 40 in its less fuel efficient days.
Do they really though? Those numbers don't actually mean that your car really will get 26 MPG in the city, they mean that the car got 26MPG in a specific test, and testing standards have changed over the years. What is an advertised 26 MPG now may not have been the same as an advertised 26 MPG 15 years ago.
Yes, they do. That was not the advertised rates for two of the three vehicles. My Mazda3 gets pretty much as advertised, and sometimes a little better; but no, I was not going off the advertised EPA guidelines.
Except, it isn't. Less fuel economic cars get raped. It isn't just about everyone driving SUVs, but think of the poor family that cannot afford anything then that clunker from the 1980s. They are not getting the same mileage as the rich guy who decided to either "save" money or be more eco-friendly with his Hybrid. The cost of a hybrid is significantly more in some cases then its all fuel counterpart. So, in this case, the poorer are paying for the roads, while the richer are using less fuel and therefore paying less taxes, even if they are driving more.
Except aren't the newer cars LESS fuel efficient? I know my new 2005 Mazda3 gets between 26 MPG city and 32 MPG highway, and my parent's old 1987 Omni got something like 29 city/35 highway - and at times as high as 40 in its less fuel efficient days. I'm also aware my their 1983 Celebrity was at least as good as my Mazda3. So I have a hard time finding that something with a "clunker from the 1980's" is getting worse mileage than newer vehicles.
Granted the horsepower is not as high - the Celebrity would have been the lowest of the three vehicles, and the Mazda3 would be the highest. Only two things with this respect are important - (i) acceleration and (ii) miles-per-gallon. Acceleration is only important in getting going; HP, torque, and transmission gear selection together drives this.
Now I could be wrong, but I believe it is a relatively common complaint that older vehicles got better mileage per gallon. Some vehicles (e.g. Suburban, Hummer, etc.) won't hold to that, but the vehicles that the Average Joe is buying falls into this.
Unfortunately, the owner and most of the staff are radical Christians with a massive persecution complex
Your statement is quite misleading - and should be revised. You make it sound as if all "radical Christians" are involved in deceptive and illegal business practices - which is certainly NOT TRUE. I'd submit that they are not following their faith in their deeds - something their local church and community should be reprimanding them for.
Bad business practices, which you are referencing, are not indicative of any particular religion or faith, etc - just bad businessmen that could care less about using their resources wisely. (FYI - true "radical christians" would be very concerned with being good stewards of their resources in both word and deed. Your evidence, if true, shows that these people are not so.)
So please, drop all the overtones and say what you really meant to say about these people & their company:
Where they once hired good photographers to work for them, they now recruit sub-par photographers - and the owner has threatened former clients and employees, in addition to "cost cutting techniques" like dumping used fixer into the town sewer system. He is not a nice person.
internally I shouldn't be passing error codes around because there shouldn't be errors.
True, there should not be. However, timing and other environmental effects in which the software runs could cause such errors. So, doing so and treating your own code like you would external code makes the program stronger, safer, less problematic, and more robust overall. Trusting any code - internal or external - is an error itself, at least IMHO.
(Also, there's no way to detect an invalid pointer in pure C++. NULL, sure. Invalid? Nope.)
True, you can only check whether a pointer is NULL in C or C++. Truthfully, I think the base libraries (e.g. standard C lib, etc.) should be able to tell you what the sizes of the memory chunks are that the pointer points to, and whether or not the pointer is valid in the sense of (a) if it was free'd, and (b) it is heap or stack memory - it would be very helpful to have a call(s) do to so. This should be easily extendible from the OS memory management functions, as well as the base libraries' own wrappers to those functions (e.g. C's malloc/free, C++'s new/delete, etc.).
But, since we cannot do that as yet, we can check whether the pointers are valid - in the sense of NULL or NOT NULL - and handle appropriately. Also checking that data is within valid ranges, and checking that double pointers are what is expected too.
Now, if you were to do this on all your functions at start/end whether or not they are internal or external, and generate and handles errors in all locations, then you should, more likely than not, not need to do the consistency checks in the middle of your functions and your programs should be able to die gracefully without crashing, allowing you to put data into the logs, etc. so you have better data to go on when you are trying to figure out what the problem(s) was(were) that caused it.
In the end, Apple's move doesn't change our opinion that the best way to acquire digital music remains buying the CD: You can rip and encode it at any bit rate you want, you can transfer it to any device you want, you know you won't have any DRM issues to worry about, and you won't have to pay anything extra for it.
Per the DRM & CD's - that's not entirely true. They have been messing with the CD headers for a while, so some newer discs won't play in older players, or even under certain operating systems. For example, I have a Beach Boys CD that I could not play under Linux because they foobar'd the headers on the disc for DRM; Windows ran it just fine; so I ripped it under Windows. I've had other discs not do too well with ripping (the disc sounds great, but even the ripped WAV doesn't).
They are working on putting DRM into CDs, and make it so that you cannot rip a CD to make MP3, etc. It'll be a losing battle, but they are trying.
If I get internal consistency faults in my program, it damn well should crash because nobody will be able to trust what it does next. Of course, that shouldn't be possible, but I've found by far the best way to keep internal consistency faults away is to make sure that they're detected ASAP and fixed. And that's where asserts come in.
And when are you doing these checks? At the start of a function - verifying the input? If so, then a return value works better and lets the caller handle the issue, and you've done minimal efforts. You can also protect your code against bad data easily this way.
Now, if you are performing a sanity check in the middle of a function - that could be a different issue. But if your function called another function, and that function did something...well...checking the error codes from the return should give you what you need to know. It may be that you continue and escalate the error out, and ultimately terminate the program. But TRY to handle all the errors you can.
Unknown errors are not always bad things. It could be that the API changed slightly and added a new error code that you don't yet handle. Such a code should be brought to the user so that it can be reported to the support team so that it does get handled.
Now, if you are able to magically determine that someone has clobbered your entire system - that would be great news to share with the rest of us. Me? I stick to what I've said about asserts - and I've written successful programs accordingly so I do know what I'm talking about.
I've also laid out frameworks from which programs will be built. If you handle it early on (without asserting) you have a far better chance of being able to handle it. Furthermore, if you do your defensive programming right (e.g. everything is checking the input values to verify before doing any processing), then you will catch the error before it causes a problem; and if you check the errors returned properly, then you can report what the real issue is.
If you are doing your coding right - then you are checking inputs to functions and outputs of functions. If your coding is right, then you will catch an out-of-bounds error BEFORE it clobbers your stack, and you will catch the invalid pointer BEFORE it causes a seg-fault. Anything else is laziness of the programmer.
So, I still propose to you that Assert()s are absolutely wrong. There are far, far better ways to handle the issues.
The only time software should truly error out - is when the hardware fails. Software should be able to catch and handle everything else; if it doesn't - the programmer who wrote it is too lazy. This means that programmers of all levels of the system must ensure the software does its job to catch and handle the errors and do so appropriately. Assert() is not appropriate in 99+% of cases.
Tip 4: Warning messages don't work. Don't bother with them. Use assert() - if it triggers, your program will crash with a useful error message. Now that's an incentive to make things work!
Absolutely WRONG!!!!
Assert()s are okay in a very, very limited scenario - but if you are writing truly robust code, you will do whatever you can to handle any error. If you end up in a state that you do not know, then error out and say it - the level above you might know what to do, and it may not be crash the program. At least with warning messages you have something to go on when (a) debugging and (b) maintaining the program.
Furthermore, Assert() is usually optimized out for "release" builds to no-op's. So then what happens if the condition didn't occur in your debug build (where Assert() would have theoretically caught it) but does happen in the release build? What happens if it happens in your customer's environment, but not in your environment because the timing is different?
Really, the only true answer is get rid of assert() - it's a classroom toy - and do the job right - handle the error like a man (or woman). There is no excuse for not writing robust and maintainable code, and as the author of the article points out - you'll love yourself if you do, and hate yourself if you do not.
Sadly, I've seen worse in the real world...something like the following:
Void change_score(short num_points) { if (num_points < 0){ // // maybe some error message // return; } score += num_points; if (num_points > 0){ make_sparkles_on_score(); return; } return; }
Only, going on for 3, 4, or more block depth levels, and for several hundred lines at a time - with no, or little, error checking, etc. Not fun stuff to maintain - and one of the first things I do is make the code sane to read. Then I can start maintaining it.
Note: I only added a single return and two braces. The code does the same thing as the parents quoted code.
There isn't anything wrong with 2007.0 release itself, but there is a lot of scope for improving the live versions.
I recently installed Gentoo 2006.1 on a system at home in the process of upgrading my server to a new box. The old system was running Slackware and has been stable for years, but is slower than the new system and I haven't updated the packages in quite a while. (Security concerns.) So I decided to give Gentoo a try as I build a new box. Gentoo 2006.1's LiveCD for x86 worked just fine; though I made a few mistakes with it. Since Gentoo 2007.0 came out, I decided to wipe the 2006.1 install and rebuild with 2007.0 - needless to say, there were problems. And, btw, this was with the CD - since I didn't have BitTorrent on my system I couldn't try the DVD.
First, it would get so far in the boot process and then start complaining about not having enough space to create stuff - despite 160MB RAM and two swap partitions nicely sized that could have been used, but I couldn't even log in as root to turn on the swap partitions.
Second, the install hung when trying to load X. I had to use the case's reset button to recover.
I can't say if there were other problems with the LiveCD as that is about as far as I got with the it. I switched to the minimal CD and have been happily installing since, albeit a slower process - but I'm learning more about the Gentoo way of things, and am quite happy about that. Still, it would have been nice to be able to use the LiveCD instead of having to download stage3 and portage.
Needless to say, I might wait until 2007.1 to install Gentoo on my Desktop.
Think of it as a wishlist, but you don't get any damn ponies.
This is really more a feature you should have than an item for a wishlist...
You're targeting the Windows platform. So you should hook your management system into the Windows Installer system (MSI). There are a number of documented interfaces (see msdn.microsoft.com) that can be used. This will provide (a) the ability for programs in your system to appear on the Add/Remove programs list (it'll still go through your installer if you get the scripts hooked right), and (b) you may even be able to manage programs already installed through native (MSI) or other installers as well.
Also, I would recommend you follow a path more like SubVersion when it comes to the scripting side of things. For example, do not define the "CygWin Sh" as being part of it. Rather, define an interface in a language like Python (no, you do not have to use python itself - you could use Perl or Windows Scripting Host or whatever). This will give you (i) a bit more portability, and (ii) the ability to do more stuff. As awesome as bash shell scripting may be, it's just not for the Windows environment, and you will not get as many users of your system if you use it.
Try to make your system as native as possible with as few dependencies as possible. Subversion, for example, will typically bundle a library for the python engine with their Win32 releases. So you don't have to install python yourself. Fewer dependencies means better, more portable functionality. And when it comes to Windows, the more native you are the more users you will attract.
As an example, I ran a program that required 100% native Windows functionality. Even putting our build system under MingSYS to get environment portability (so we could port to Linux/Unix using the GNU AutoTools toolchain) was not allowed. This was especially true when it came to the installer. We could not tell someone to go install another program so they could install or use our program. I am now looking at CMake as a replacement for the GNU AutoTools toolchain as it provides native support on the platforms I need. So please, please, please do yourself and the rest of us a favor and build native tools that do not have much external dependencies. Subversion does it. CMake does it. KDE is even moving that direction and providing Windows support (with CMake, btw).
No, writing programs that do parallel processing (whether using threads or processes to do it) is really quite easy. You do need to have a good background in programming before you take up the challenge, though, or you will really mess it up - but that is true for any more advanced technique in a field - you need to know the basics to do the advanced stuff.
Single threaded apps are really the basics of programming, and today's environments really, really require multi-threaded/multi-processed apps. For example, GUI environments usually require having a thread dedicated to handling the GUI interface, and running lots of worker threads to perform the various tasks. (If you get a GUI program whose window hangs on you, it is because either (a) it was not written correctly and does not use a dedicated thread to handle its GUI, and/or (b) it got stuck waiting on something. 'a' is the more likely cause.)
Now, what can be a bit difficult is determine what parts of the program to offload to another thread. And the simple answer there is anything that could block the program if it does not return fast enough. (Fast enough being
The problem simply becomes that we do not want to do it because we think it is hard. And it is not a matter of language issues either. Certainly some languages may make it easier, but it is easy to do multi-threaded and multi-processed programming in C and C++ - OO makes it even easier. What programmers need to learn is how to use locking mechanisms correctly to protect the data, and how to write code that will keep locks for minimal amounts of time in order to minimize possible locking conflicts. (OO's Get/Set methodology helps this tremendously.)
So, no - it is not hard. Most programmers are just to lazy to learn how and/or attempt it. Reality is, if you want to maintain a responsive interface you have to do it.
FYI - I've been doing this very thing for a quite while now, and in C/C++ in a Win32 environment none-the-less. I've also done similar work under Linux. When you architect your program correctly, it becomes really easy to do. I would offer that the real cause is that software programmers don't do enough software engineering for their programs; so everything happens in chaos, which does make it difficult to do. (Thus the perception of being hard, and the laziness of programmers in doing it.)
Add costs of storage:
Figure a sunk cost in an extra rack in the basement where space already exists. The server room guys will have to find a way to fit around the extra rack (where I work, this is a perfectly-reasonable assumption; we have hundreds of racks just in our headquarters)...
Sure - if your business owns the property. A lot of businesses do not. If you are replacing an old system, then it may not be as much, but if you are putting in a new system, then you may have to get more space - and that is a monthly cost that can easily be at least a few thousand (depending on where you are - e.g. L.A vs. D.C. vs Johnstown PA).
This assumes over some period of time that the following are true:
1) Hardware engineers do not develop faster computing architectures and hardware
2).NET and Java aren't improved in their execution efficiency
3).NET and Java programmers are incapable of improving their skills
Actually:
#1 would mean that a new investment in hardware would have to occur, so another couple hundred thousand (using your numbers) for such a return.
#2 - efficiency may occur, but as a matter of fact they will always be slower than native code. That is an unchangeable principle.
#3 - they may improve their skills, but that doesn't mean the engine will improve.
What I presented simply shows that up front work is cheaper than long term costs to run because the up-front work brings an efficiency that works to its advantage over the long term.
they do pretty indisputably do a good job (generally) of cutting short-medium-term costs.
But usually at the cost of their long term costs and health.
How can a closed license be preferable to BSD, when BSD is basically "do whatever you want with it", including closing the source?
Because they don't understand licensing. I've run into the same kind of thing with public domain software. Couldn't plug it in because they didn't understand that you didn't have to pay (or worry about legal issues with) public domain software, but were concerned support might not be there. Well - we had the source, but couldn't integrate it. So it the feature it would have supported got dropped.
It's easy to measure a business plan against. That's not to say it would necessarily encourage wasteful management, as the business plan itself would be under scrutiny and the cost part would have to be justified. Could you justify 5 engineers, and 10 people in management for designing a new toothbrush? Not likely. (And yes, I am familiar with how some of that goes.)
True - the proposed system does, as you say, give little weight and little RIO on inventions that cost little but have huge societal benefits. To a degree that was intentional - to keep from having every little thing no matter cost to invent patented, and to help kill off patent trolls and trivial inventions - but perhaps there could be an exception clause for extremely low cost inventions that some how weights the societal value in instead of cost, but the patentee would have to justify the need to fall under that exception, and it should be an exception that is hard to obtain. (Otherwise it would be abused.)
Per the cost plus contracts - this would not quite work that way. Cost Plus contracting means that you get to submit your costs as part of the contract, and they are not subject to much scrutiny (though there is some, and the customer does have some say over how you spend the money). This, on the other hand, would be subject to much scrutiny, and cost would need to be strictly defined as what did it really cost to invent, likely even as unburdened labor, etc. (Cost plus contracting you get to submit burdened labor.) Your books would be opened to see the cost. If you hired 1 manager and 5 engineers to make the invention, and you paid them $60k, as well as spent $100k in equipment, capital, etc - than $160K is your cost.
Essentially, this pushes more for smaller organizations to invest larger chunks of money to invent. The idea is to level the playing field more, and ensure that the public has some better say over how long a patent or copyright is granted for.
It's cheaper to implement for a 16 core, 8GByte RAM box than it is to pay a developer to optimize the code so it can run on a single 486DX2/66...
That depends on how you do your calculation. If you compare the cost of the developer's time to write the application and optimize it, as well as the cost of the hardware, and running the hardware (space to keep it, electricity, wires to connect it all, etc.) I would be willing to bet (if I bet, which I don't) that it would over the life of the program come out no more expensive. The fact of the matter is that it costs money to run hardware - money for the electricity, money for the hardware itself, money to connect it all, and money to keep it someplace - and that adds up, and can add up very quickly.
So, compare this - if your application cost $3M to develop the "cheap" way, and cost $6M to develop the "expensive" way...but the cheap way requires that you have 20 computers to perform the same task load as 5 computers for the "expensive" way, what did you save? Nothing. In fact, on those numbers your "cheap" application will mean that you will have to have higher costs for the entire life of the application to run those 20 computers - and that will add up to a lot more than the $3M difference.
Now, if those 20 computers were identical to the 5 computers, the above would be even more true. (For reference in the following we'll notate those computers as "Z" computers.) Though you could also argue that (depending on the program) you might be able to get 5 "Y" computers that could do the load of the 20 "Z" computers, but then you hardware costs are still going to be higher than the original 5 "Z" computers and the costs to run those 5 "Y" computers would still be higher. So, in the end - it still costs more to actually run the "cheap" program than it does to run the "expensive" program.
So - no. The "hardware is cheaper" argument is not valid, and never will be.
Also, you are not guaranteed that computers tomorrow will be faster than computers today, even though that has historically been true. For example, dual core systems are using two slower cores to produce a single processor that performs as fast as a single faster core could to do the same workload. (Moore's Law is still upheld since it really applies to density of the circuitry not the speed. But programmers cannot count on speed increases.) The applications will not run as fast on those slower cores as they would on the faster core, yet the application programmers (especially.Net and Java programmers) are counting on faster processors (and faster cores) to make up for their slower programming environments. It just does not work.
Although I like the idea of having different patent terms for different industries (which we kind of have already in the distinction between patent and copyright), I disagree with the business plan approach. That model would involve a substantially increased degree of government control over industry, with many opportunities for trollish lobbying. Once you have the IRS and SEC reviewing a plan from year to year to decide how much profit is "enough," others will want a seat on the review board. Just imagine Jack Thomson demanding that the latest patent be invalidated because it's being used to make ultra-realistic violent video games!
I would not leave that percentage profit to the whims of the review board, but would codify it in the law that sets up the reform. True, companies would likely try to sway congress to change that percentage...however, at the same time it could very well be used against Congress. So as long as it is codified in law it become a political influencer both ways, and will be fought over just like taxes, etc.
The only real problem I see with my own plan would be the cost to implement, and the burden on those patenting to get a patent. It will be raise the cost to get a patent, but it should lower the cost in the long run as far the USPTO goes. So, there are tradeoffs.
But regardless, I would not leave it to the whims of the review board. Their only job would be to evaluate how the business plan is going, and to revoke the patent when the cost+profit is met. It might be good to also have codified that patents only get the cost+profit at time of file or granting instead of whatever it may be at time of review, i.e. changes to the percentage profit should not be retroactive to existing patents.
Industry would likely be able to buy into this if there is a grandfather clause for existing patents in the existing system such that they will exist under current law until their terms expire, and extensions would have to be provided under the new system.
A reform would actually bring you more money." then it will never happen.
My reform mentioned in this post would make the gov't more money than they are making now. It would also (a) make lawyers a lot more money, and create a whole new class of gov't workers that deal with business plans, so people with MBA's will make more money too. How about we propose it up? That should take then, no?
Reality is that it is business and patent trolls that are fighting against patent reform. Even the USPTO has recognized a problem and been trying to reform some, and even Congress has been doing work towards that too. That's how we got the public peer reviews of patents going. So, yes, it is all about money, but it is more about whose money. Patents make a lot of money for a lot of people, gov't and business included; and until businsses get in line and say we need reform (which is starting to happen), then only have the stakeholders involved are for it, and the other half are against it and pay for the elections of the other half.
Slashdot Mirror
However, for someone that is not a public person it is harder to show that they would carry weight in what they say, thus they would not be libel.
Now, if an executive of a competitor said something, then they would be under the same rules as Oprah.
At least in the US, the law does give weight to (a) how public a person is, and (b) how much weight a persons word carries. Additionally, a person cannot be found libel if what they said is indeed true. Libel only applies if the statement is false or (possibly) extremely misleading.
This is also why you generally do not find competitors explicitly bashing each other. For example, this is why Apple uses the name "Mac" and "PC" in their commercials, even when it is obvious that they are meaning "Mac" and "Windows".
Another major fallacy. Only a few networks even have commentators that even discuss both sides of an issue. Those that do not discuss both sides tend to be very much on the far left - no where near center, let alone the right. (Yes, that's ABC, CBS, NBC, MSNBC, CNN, NY Times, Washington Post, Wall Street Journal, USA Today, and pretty much all other major news outlets in the US. Fox News is the only one I'm aware of that even discusses both sides.)
So, for the $5M in 2007 dollars (using the same inflation calculator), IBM is really getting $3,373,423.29 1992 dollars - a savings for the district of $1,626,576.71 1992 dollars.
To be really accurate you'd have to wait until each of the years in the contract passed to calculate how much IBM really lost out. It's likely a few hundred grand more than the above calculations. We just can't know until we can compute the difference by inflation, which could probably be approximated at about 1.5% to 3% per year going forward.
Now if only it were true...and realistic...
It was more that none of them (scientists, religious folks, and the rulers) wanted to be wrong and anyone who said otherwise was put to death. This is perhaps the primary issue - and one that goes with most monarchy governments, as well as any other kind of government where a single person or small ruling class are in charge: say the ruling class is wrong, and risk your life. It has nothing, really, to do with religion.
This often gets confused as a religious consensus because the ruling class (e.g. the monarchy's) also set forth the religious practices and beliefs. However, the two are otherwise not really that much connected - it was about equally scientific pushed, and was held by the scientific community at that time quite strongly.
For starters, the only real gadgets I have is my cell phone and a few computers. I got a couple other things the are work related, but don't do anything really (not a crackberry, pda, etc.). However, while a true nerd/geek - I could just as easily drop all the gadgets and computers and go do something else with my life - write books, play music, etc. There's not a thing technology has that I really need. (And by technology, I am referring to computer related stuff.) Advances in medicine, etc. are great and useful, and my wife certainly needs them (asthma).
If my bank weren't 600 miles away (no local branches, and I don't want to change banks either), then I could do without a credit/debit card too. Of course, I could do that and just use a checkbook too, not a problem; though I'd much prefer going to cash. (I also have a book on managing money; and the author found that by going to only using cash one would spend roughly 34% less money than by other means - namely credit/debit cards.)
Now, of course you could get picky about what you want to call a gadget. And if you really wanted to do so, then you'd pretty much have to consider most vehicles gadgets these days too, and with that respect - while I'd prefer to keep my car due to family being spread out across a few states, I could otherwise go without it without much problem. It'd take me a little longer (at present) to get to work - 20 minutes instead of 10 - but would be well worth it.
So I guess the real question is - what does this "first world" lifestyle really have to offer that is needed? Well, not much really. Most of what is really needed is provided simply by the sanitization and quality levels (e.g. food, drugs, etc.). Most anything else we could do without quite easily. Sure, it won't be the same, but we'd probably all enjoy life a lot more.
And, fyi, I am not joking by the above. I quite often go without touching a computer for a few days; I have gone months without a TV; I can even easily go a few days without using my cell phone. My current line of work is what keeps me on a computer and the Internet most of the time, but if I changed that I could easily fall off-grid and not even realize it.
This is the real reason why the FCC and Congress are pushing for HDTV. They see the Billions of dollars that it could bring in in profit. A newspaper article I came across back in the late 90's, when HDTV was suppose to go live and SDTV was suppose to be shutoff in 2001, had an estimate of $4.2 Billion USD that the SDTV spectrum would go for at that time. It's probably a lot higher now.
So, to MPAA, RIAA, NASCAR, NFL, NBA, ABL, NHL, etc. all want HDTV so they can control what you can watch, how you watch it, what you watch it on, etc; and the US Gov't wants HDTV so they can make billions of dollars in pure profit.
I'm not saying that we couldn't use the SDTV more effectively (or even AM/FM frequencies for that matter); but this is not something that is in the consumer/customer's interest. It's all $$ motivated.
Btw, in my vehicles, I have seen ethanol halve the MPG with no other change. I don't know what goes into the CAFE fleet calculations; however, it seems to me from several different vehicles that they seem to set the size of the tank based on a common mileage per tank figure of about 400 miles per tank (full to dry empty). My 2005 Mazda3 with a 14 gallon tank, my previous 1994 Grand Marquis with a 20 gallon tank (the Mazda3 replaced it), my wife's Infiniti J30 with a ~20 gallon tank, and several other vehicles I have observed all get about 400 miles per tank, though their miles per gallon varies widely. I don't know why it is 400 miles per tank, but that seems to be a commonality between the vehicles. (This is based on the fact that they all seem to get about 100 miles per quarter tank; though I did push the Grand Marquis to nearly 400 miles on a tank once - then I put in 19.76 gallons; I was within 5 or 10 miles of the 400 mile mark on the trip odometer.)
Granted the horsepower is not as high - the Celebrity would have been the lowest of the three vehicles, and the Mazda3 would be the highest. Only two things with this respect are important - (i) acceleration and (ii) miles-per-gallon. Acceleration is only important in getting going; HP, torque, and transmission gear selection together drives this.
Now I could be wrong, but I believe it is a relatively common complaint that older vehicles got better mileage per gallon. Some vehicles (e.g. Suburban, Hummer, etc.) won't hold to that, but the vehicles that the Average Joe is buying falls into this.
Please correct if I am wrong.
Bad business practices, which you are referencing, are not indicative of any particular religion or faith, etc - just bad businessmen that could care less about using their resources wisely. (FYI - true "radical christians" would be very concerned with being good stewards of their resources in both word and deed. Your evidence, if true, shows that these people are not so.)
So please, drop all the overtones and say what you really meant to say about these people & their company:
But, since we cannot do that as yet, we can check whether the pointers are valid - in the sense of NULL or NOT NULL - and handle appropriately. Also checking that data is within valid ranges, and checking that double pointers are what is expected too.
Now, if you were to do this on all your functions at start/end whether or not they are internal or external, and generate and handles errors in all locations, then you should, more likely than not, not need to do the consistency checks in the middle of your functions and your programs should be able to die gracefully without crashing, allowing you to put data into the logs, etc. so you have better data to go on when you are trying to figure out what the problem(s) was(were) that caused it.
They are working on putting DRM into CDs, and make it so that you cannot rip a CD to make MP3, etc. It'll be a losing battle, but they are trying.
Now, if you are performing a sanity check in the middle of a function - that could be a different issue. But if your function called another function, and that function did something...well...checking the error codes from the return should give you what you need to know. It may be that you continue and escalate the error out, and ultimately terminate the program. But TRY to handle all the errors you can.
Unknown errors are not always bad things. It could be that the API changed slightly and added a new error code that you don't yet handle. Such a code should be brought to the user so that it can be reported to the support team so that it does get handled.
Now, if you are able to magically determine that someone has clobbered your entire system - that would be great news to share with the rest of us. Me? I stick to what I've said about asserts - and I've written successful programs accordingly so I do know what I'm talking about.
I've also laid out frameworks from which programs will be built. If you handle it early on (without asserting) you have a far better chance of being able to handle it. Furthermore, if you do your defensive programming right (e.g. everything is checking the input values to verify before doing any processing), then you will catch the error before it causes a problem; and if you check the errors returned properly, then you can report what the real issue is.
If you are doing your coding right - then you are checking inputs to functions and outputs of functions. If your coding is right, then you will catch an out-of-bounds error BEFORE it clobbers your stack, and you will catch the invalid pointer BEFORE it causes a seg-fault. Anything else is laziness of the programmer.
So, I still propose to you that Assert()s are absolutely wrong. There are far, far better ways to handle the issues.
The only time software should truly error out - is when the hardware fails. Software should be able to catch and handle everything else; if it doesn't - the programmer who wrote it is too lazy. This means that programmers of all levels of the system must ensure the software does its job to catch and handle the errors and do so appropriately. Assert() is not appropriate in 99+% of cases.
Assert()s are okay in a very, very limited scenario - but if you are writing truly robust code, you will do whatever you can to handle any error. If you end up in a state that you do not know, then error out and say it - the level above you might know what to do, and it may not be crash the program. At least with warning messages you have something to go on when (a) debugging and (b) maintaining the program.
Furthermore, Assert() is usually optimized out for "release" builds to no-op's. So then what happens if the condition didn't occur in your debug build (where Assert() would have theoretically caught it) but does happen in the release build? What happens if it happens in your customer's environment, but not in your environment because the timing is different?
Really, the only true answer is get rid of assert() - it's a classroom toy - and do the job right - handle the error like a man (or woman). There is no excuse for not writing robust and maintainable code, and as the author of the article points out - you'll love yourself if you do, and hate yourself if you do not.
Note: I only added a single return and two braces. The code does the same thing as the parents quoted code.
First, it would get so far in the boot process and then start complaining about not having enough space to create stuff - despite 160MB RAM and two swap partitions nicely sized that could have been used, but I couldn't even log in as root to turn on the swap partitions.
Second, the install hung when trying to load X. I had to use the case's reset button to recover.
I can't say if there were other problems with the LiveCD as that is about as far as I got with the it. I switched to the minimal CD and have been happily installing since, albeit a slower process - but I'm learning more about the Gentoo way of things, and am quite happy about that. Still, it would have been nice to be able to use the LiveCD instead of having to download stage3 and portage.
Needless to say, I might wait until 2007.1 to install Gentoo on my Desktop.
You're targeting the Windows platform. So you should hook your management system into the Windows Installer system (MSI). There are a number of documented interfaces (see msdn.microsoft.com) that can be used. This will provide (a) the ability for programs in your system to appear on the Add/Remove programs list (it'll still go through your installer if you get the scripts hooked right), and (b) you may even be able to manage programs already installed through native (MSI) or other installers as well.
Also, I would recommend you follow a path more like SubVersion when it comes to the scripting side of things. For example, do not define the "CygWin Sh" as being part of it. Rather, define an interface in a language like Python (no, you do not have to use python itself - you could use Perl or Windows Scripting Host or whatever). This will give you (i) a bit more portability, and (ii) the ability to do more stuff. As awesome as bash shell scripting may be, it's just not for the Windows environment, and you will not get as many users of your system if you use it.
Try to make your system as native as possible with as few dependencies as possible. Subversion, for example, will typically bundle a library for the python engine with their Win32 releases. So you don't have to install python yourself. Fewer dependencies means better, more portable functionality. And when it comes to Windows, the more native you are the more users you will attract.
As an example, I ran a program that required 100% native Windows functionality. Even putting our build system under MingSYS to get environment portability (so we could port to Linux/Unix using the GNU AutoTools toolchain) was not allowed. This was especially true when it came to the installer. We could not tell someone to go install another program so they could install or use our program. I am now looking at CMake as a replacement for the GNU AutoTools toolchain as it provides native support on the platforms I need. So please, please, please do yourself and the rest of us a favor and build native tools that do not have much external dependencies. Subversion does it. CMake does it. KDE is even moving that direction and providing Windows support (with CMake, btw).
And - fyi - you don't need Cygwin to do it.
No, writing programs that do parallel processing (whether using threads or processes to do it) is really quite easy. You do need to have a good background in programming before you take up the challenge, though, or you will really mess it up - but that is true for any more advanced technique in a field - you need to know the basics to do the advanced stuff.
Single threaded apps are really the basics of programming, and today's environments really, really require multi-threaded/multi-processed apps. For example, GUI environments usually require having a thread dedicated to handling the GUI interface, and running lots of worker threads to perform the various tasks. (If you get a GUI program whose window hangs on you, it is because either (a) it was not written correctly and does not use a dedicated thread to handle its GUI, and/or (b) it got stuck waiting on something. 'a' is the more likely cause.)
Now, what can be a bit difficult is determine what parts of the program to offload to another thread. And the simple answer there is anything that could block the program if it does not return fast enough. (Fast enough being
The problem simply becomes that we do not want to do it because we think it is hard. And it is not a matter of language issues either. Certainly some languages may make it easier, but it is easy to do multi-threaded and multi-processed programming in C and C++ - OO makes it even easier. What programmers need to learn is how to use locking mechanisms correctly to protect the data, and how to write code that will keep locks for minimal amounts of time in order to minimize possible locking conflicts. (OO's Get/Set methodology helps this tremendously.)
So, no - it is not hard. Most programmers are just to lazy to learn how and/or attempt it. Reality is, if you want to maintain a responsive interface you have to do it.
FYI - I've been doing this very thing for a quite while now, and in C/C++ in a Win32 environment none-the-less. I've also done similar work under Linux. When you architect your program correctly, it becomes really easy to do. I would offer that the real cause is that software programmers don't do enough software engineering for their programs; so everything happens in chaos, which does make it difficult to do. (Thus the perception of being hard, and the laziness of programmers in doing it.)
- #1 would mean that a new investment in hardware would have to occur, so another couple hundred thousand (using your numbers) for such a return.
- #2 - efficiency may occur, but as a matter of fact they will always be slower than native code. That is an unchangeable principle.
- #3 - they may improve their skills, but that doesn't mean the engine will improve.
What I presented simply shows that up front work is cheaper than long term costs to run because the up-front work brings an efficiency that works to its advantage over the long term.But usually at the cost of their long term costs and health.
True - the proposed system does, as you say, give little weight and little RIO on inventions that cost little but have huge societal benefits. To a degree that was intentional - to keep from having every little thing no matter cost to invent patented, and to help kill off patent trolls and trivial inventions - but perhaps there could be an exception clause for extremely low cost inventions that some how weights the societal value in instead of cost, but the patentee would have to justify the need to fall under that exception, and it should be an exception that is hard to obtain. (Otherwise it would be abused.)
Per the cost plus contracts - this would not quite work that way. Cost Plus contracting means that you get to submit your costs as part of the contract, and they are not subject to much scrutiny (though there is some, and the customer does have some say over how you spend the money). This, on the other hand, would be subject to much scrutiny, and cost would need to be strictly defined as what did it really cost to invent, likely even as unburdened labor, etc. (Cost plus contracting you get to submit burdened labor.) Your books would be opened to see the cost. If you hired 1 manager and 5 engineers to make the invention, and you paid them $60k, as well as spent $100k in equipment, capital, etc - than $160K is your cost.
Essentially, this pushes more for smaller organizations to invest larger chunks of money to invent. The idea is to level the playing field more, and ensure that the public has some better say over how long a patent or copyright is granted for.
So, compare this - if your application cost $3M to develop the "cheap" way, and cost $6M to develop the "expensive" way...but the cheap way requires that you have 20 computers to perform the same task load as 5 computers for the "expensive" way, what did you save? Nothing. In fact, on those numbers your "cheap" application will mean that you will have to have higher costs for the entire life of the application to run those 20 computers - and that will add up to a lot more than the $3M difference.
Now, if those 20 computers were identical to the 5 computers, the above would be even more true. (For reference in the following we'll notate those computers as "Z" computers.) Though you could also argue that (depending on the program) you might be able to get 5 "Y" computers that could do the load of the 20 "Z" computers, but then you hardware costs are still going to be higher than the original 5 "Z" computers and the costs to run those 5 "Y" computers would still be higher. So, in the end - it still costs more to actually run the "cheap" program than it does to run the "expensive" program.
So - no. The "hardware is cheaper" argument is not valid, and never will be.
Also, you are not guaranteed that computers tomorrow will be faster than computers today, even though that has historically been true. For example, dual core systems are using two slower cores to produce a single processor that performs as fast as a single faster core could to do the same workload. (Moore's Law is still upheld since it really applies to density of the circuitry not the speed. But programmers cannot count on speed increases.) The applications will not run as fast on those slower cores as they would on the faster core, yet the application programmers (especially
The only real problem I see with my own plan would be the cost to implement, and the burden on those patenting to get a patent. It will be raise the cost to get a patent, but it should lower the cost in the long run as far the USPTO goes. So, there are tradeoffs.
But regardless, I would not leave it to the whims of the review board. Their only job would be to evaluate how the business plan is going, and to revoke the patent when the cost+profit is met. It might be good to also have codified that patents only get the cost+profit at time of file or granting instead of whatever it may be at time of review, i.e. changes to the percentage profit should not be retroactive to existing patents.
Industry would likely be able to buy into this if there is a grandfather clause for existing patents in the existing system such that they will exist under current law until their terms expire, and extensions would have to be provided under the new system.
Reality is that it is business and patent trolls that are fighting against patent reform. Even the USPTO has recognized a problem and been trying to reform some, and even Congress has been doing work towards that too. That's how we got the public peer reviews of patents going. So, yes, it is all about money, but it is more about whose money. Patents make a lot of money for a lot of people, gov't and business included; and until businsses get in line and say we need reform (which is starting to happen), then only have the stakeholders involved are for it, and the other half are against it and pay for the elections of the other half.