A single announcement wouldn't be used that way on it's own, it's simply a way to condense a text announcement down to [an indicator]...The genetic algorithms which give too much or too little weight to the announcements will predict badly and fail to thrive.
I guarantee you that if you put some serious time into this approach, you'd discover that the weight of any "announcement tone" indicator would end up so close to 0 that computing it in the first place would be a waste of time. Here's a better indicator: watch what the price of the stock does for the first few seconds the market is open after the announcement. Whatever direction it moved in, there's your answer for whether the announcement was good or bad from the perspective of stock price. If you put those two indicators in a genetic optimizer cage max, the fancy sematic news-reading approach is going to be left in a puddle of blood every time, squashed by a stupid but very strong indicator whose sole mantra is "the market moves the way it moves".
So a revision upwards should be more likely to bump a stock than to tank it (though it might be a close thing).
Market theorists love to point out with much amusement that a lot of things that seem like they would be strongly associated with a clear move in one direction turn out, after you analyze them properly, to be close to 50/50 that you can't trade on them usefully.
It seems like first impressions would matter a lot in such cases. You know, simple metrics like "increased earnings == good", "layoffs == outstanding", "merger == cha-ching", "merger with layoffs == do-money-dance"...A basic system seems like it would have a better chance at predicting knee-jerk movements rather than the ones resulting from a few more moments consideration.
Let me pull apart one of those as an example. If you watch a few of them, merger announcements usually have a strong impact on both companies involved. Even people have a hard time distinguishing whether a buy-out of a company is a bargain, or a big overpayment relative to the true value of the company. With the same big news announcement, one company's stock will go up, and the other's will go down, all based on the perception of whether the terms of the merger gave one party a better deal than the other. So we have one annoucement, which is likely to increase the price of one stock and decrease the other; it's a very complicated thing to predict.
And how the market will react to layoffs is dramatically more complicated even than that--layoffs as a cost-cutting measure might be good for the price, layoffs because the business is dying might kick off a gigantic selling spree, and the price can jerk around all over as big-name analysts weigh in with their opinion over the days that follow the initial news release.
I went through this whole excercise myself for a while, trying to get a computer to parse the news and do something useful with it. Turns out, there's a much easier way to figure out whether the market views something as good or bad news: just watch what the price of the stock does. You'd be far better off learning some of the techniques of technical analysis than bothering trying to understand whether the tone of a news pieces is good or bad. It would take years of training a sematic-based approach before it had any hope of being better than an approach that just looks at a few minutes of where the market is moving and assuming it's going to move in that direction more; a simple moving average crossover technique works just fine for that.
If you have a giant set of data, and you set a computer on it for long enough, it should be able to come up with some rather solid paterns/corelations/etc.
If by "solid" you mean "tradable" then no, it won't. It will produce what trading system developers refer to as a curve-fit trading system. When exposed to new market data, that type of system really doesn't work well at all.
Think about this for a minute...how well would a trading system trained on data about the.com boom work in today's market? How well would one trained on the.com bust work? Pretty bad, right? Well, guess what...you never know which type of market you're in, and the market is constantly changing. Now you're thinking "then just train against enough data that you've seen everything"...ha! Do you think that today's market, with tons of electronic trading at very low prices, move exactly the same as the ones from the 70's where individual trades costs hundreds of dollars to execute? You can either have a small amount of data that reflects how the market is working recently, or a large amount of data that's mostly about a market that doesn't work the same way the current one does; it's impossible to get a lot of data on how the current market moves, because the current market only exists a tick of data at a time.
People who actually build useful systems start with a theory about how prices move, then write code to analyze the market to see if that strategy is tradable. I would suggest you read an article by well-known traders William Eckhardt and Richard Dennis at http://www.visoracle.com/swingtrend/optimization.h tml as an initial bit of food for thought; a search on curve fitting in trading systems will lead to many, many more article on the subject of why having the computer just look for patterns on its own is of extremely limited value.
The same algorithm could be used to classify any news article as good or bad for a particular stock by looking at the direction the stock takes after the news appears. You could even train the classifier automatically by looking a couple of days in the past. Simply classify every single financial announcement against every single stock, eventually it'll get to the point that the classifier will be able to say that an announcement is 80% probably good news for this stock, 92% bad news for that stock.
If you ever tried to build such a system you'd realize the problem is exactly as hard as predicting the motion of the market as a whole. Market participants are working with earning estimation at a higher level than any current generation AI could possibly understand. Read up a bit on whisper numbers to get a feel for the challenges here. You could have an earnings report that says "earnings are up, we just increased sales, and we rule!" that doubles the price of one stock, because no one was expecting that. Meanwhile, the exact same report from another company tanks the price because people had driven the price of the stock up before the news in anticipation of even better numbers.
One trade I went through this with stands out in my memory. I had what I thought was juicy new information about recent sales trends for a company, and I purchased many shares before their earnings report expecting that sales were going to be up 40% from the previous quarter. Sales were actually up 50%. The next morning, as the market opened, instead of counting my profits I discovered the stock had dropped 15% after the announcements. Turns out, people with much better information than me had driven the price up over the previous few weeks in the expectation that sales were actually going to be up 70%. The notion that you can compete with this sort of behavior after the news announcements has come out is at best a wonderful fantasy; at worst, you'll actually try to do it and get crushed.
[Note: the following example is based on my understanding of the stock market, which is most likely wrong]
Completely, but it's good that you know what you don't know--you'd lose a lot less money trading that way. It's impossible to parse stock news and figure out if it's good or bad. Using your example, if Google announces that it will exceed its previously projected earnings, it's just as likely the stock will crash as skyrocket. This is because market participants are working with earning estimation at a higher level than any current generation AI could possibly understand. Read up a bit on whisper numbers to get a feel for the challenges here.
Regardless, the notion that you as an individual could possibly get news and act on it faster than the people that really move the market around is naive anyway. Many of these announcements are made outside of trading hours, and after-hours trading is difficult for an individual to do. By the time the regular market opens up again, the big move is already done.
At some point oracle should take a look at their own legal standpoint and community reputation (if Larry Ellison cares about that).
He doesn't.
Dozens of bloggers and community members are already calling it a failure
He also doesn't care about what people named Mookie or BS think, either. Whether it's a failure or not will come out on Oracle's next quarterly report, or maybe a few after that; you can't rule out the possibility that this is a loss-leader aimed at expanding Oracle market share. Every dollar that isn't paid to RedHat could be used to get a Oracle product instead.
Here's what I got out of your links, which were quite helpful with facts but slightly fuzzy with their conclusions from where I sit:
1) Oracle's Linux is at the moment a slightly broken copy of CentOS, and shouldn't be bothered with yet. I don't think this really matters. The people Oracle wants to sell this product to aren't the kind to install the first release, anyway; my guess is that what the bloggers are being used for is product beta testing, which they seem happy to help out the company with.
2) RedHat couldn't deliver a product this cheap on their scale of operations. So what? That doesn't answer whether or not Oracle can leech their work, re-skin it (either directly or indirectly), and then sell it at that price with the economy of scale their enormous operation has. You can bet that Oracle execs are world-class experts on how to manage a tech support operation in a way that keeps costs under control, lessons RedHat certainly didn't have a mature view of yet during the time period discussed by your second link.
This whole thing is just posturing right now; I'm going to wait until at least the second major revision from them before making premature judgements.
SMART has a mechanism for the drive makers to indicate what is and isn't a "failing" value for a particular attribute. If n bad sectors is enough to cause concern, then the drive should have said it was failing!
There's still a chicken/egg situation with SMART right now that makes this all more difficult. There are zero mainstream operating systems that have useful SMART software embedded in them. The smartmontools package for Linux works better than anything else I've found, but as you point out it's not exactly obvious what you should do with it and the drives don't handle it themselves correctly. I've spent a lot of time looking for a Windows SMART client that gives me useful results and found zero that do everything I want (I'm still evaluating whether the Windows smartmontools port can be turned into something useful, so far no success). On Mac OS, Apple gives you a report if you run Disk Utility, but not otherwise; there is free tool available to automate that, but even then I don't believe is running a self-test the way that's really needed. And no matter what you're doing, you're not going to get SMART data over USB, and you probably can't get it over Firewire either.
Beyond the brain-dead "SMART failure" notice that come up in some PC BIOSes, hard drive makers are hard pressed to find any software that actually uses SMART with a big enough client base to make it worth testing. Is it any wonder that they fail to implement all the interfaces required to make their drives emit errors robustly? There is zero market pressure from the major upstream software or hardware vendors buying hard drives for drive manufacturers to care.
What bothered me about your initial message was the implication that because SMART data is difficult to interpret, and therefore far from automatic in its current state, that it wasn't of any value. The data is hard to work with, but it does work far better than nothing--and in your case it appears your drive was giving evidence it was dying well before it really failed completely, you just weren't interpreting that correctly. As for what's wrong that it doesn't work automatically, so that we all have to become experts on interpreting SMART errors, I wouldn't place blame at the feet of the drive manufacturers for not labeling failure points correctly; there isn't enough software that reads them for that to be an important feature to implement. The right question is what it would take to have users start screaming in unison for operating system vendors to include a robust, automatic SMART check in their software by default.
Second that. The new all-you-can-eat plan from Safari has saved me a fortune in book buying, and I have to lug a lot less stuff around to be productive as well.
"I ran smartd, and occasionally took a look at the statistics with smartctl, to make sure nothing was going wrong. I had a few reallocated sectors, but nothing to cause concern."
Stop right there--"a few reallocated sectors" is always a cause for concern. Maybe not during the first month or two, but if that number is growing after the inital break-in period you should consider the drive extremely suspect. As you'll see many people in this thread comment, reallocated sectors is the #1 thing to watch for to determine when a drive is failing. I wonder whether you had smartd.conf setup correctly if that number was going up and you weren't getting warnings screaming that the drive was going bad.
Regardless, I fully support your backup-urging bell ringing, as you can never be too paranoid there, and would drop some change in your jar were I to pass you on the sidewalk.
A typical configuration for the smartmon-tools package for Linux will run a full SMART self-test every day. That test has caught three hard drive failures in the last three years for me (two Maxtors, one Seagate), all of which started screaming before any data was lost. In one of the Maxtor cases, the drive went down in flames so fast after the initial warning that I lost some data, the other two gave me enough time to make (another!) backup before tossing or RMA'ing the drive.
I have considerably less faith in any of the Windows based SMART monitoring tools, as I haven't found any that seem to run an equally rigorous test on the drive every day. As you suggest, unless you run a good test, the drive is unlikely to generate useful SMART errors until it's too late. You can go crazy staring at the low-level statistics trying to figure out whether changes in the rate of the error rates there mean anything, but when the self-test reports an error that drive is done. For me, that's been early enough to be helpful while not causing me to toss the drive before it's truly worn out.
I received both a BS and an MS in computer science at Stevens Institute of Technology back in 1993. Most of the classes people are suggesting here were all required to earn the undergrad degree there; in addition to 3 semesters of Calculus, you also had to pass discrete mathematics, statistics (two semesters of that), and linear algebra as part of the standard program.
Out of the required math classes, two stood out as being particularly helpful for my career in software development. The introductions to logic, graph theory, proof, and other topics in the discrete math course were absolutely vital to understanding more complicated computer science constructs. I recall trying to understand how compilers were built before that time and being completely confused, but everything made perfect sense after completing that class.
The other class was in operations research, a subject I didn't notice anyone bringing up here yet. OR really made an impression on me as it provided a bridge for how to apply several types of mathematical approaches that had seemed completely theoretical to solving the kinds of real-world problems computers are good at helping with. As the most obvious example, I feel that having a solid practical understanding of how to model a complicated queue or flow across a series of queues is wildly more useful for building software than anything related to big-O analysis will ever be, unless you're one of the rare people writing basic algorithm libraries. My experience is that you'll see dozens of messaging queue issues in business software design for every problem that requires an understanding of complexity analysis. And learning how formally construct decision trees turns into a great tool when you get far enough along that you're managing projects instead of just working on them. I considered it unfortunate that I didn't discover this class of mathematics until very late into my time at school, as I would have gladly taken more of it and benefitted from--something I can't say about statistics or linear algebra, where I felt the basic introduction gave sufficient understanding for normal programming tasks.
Most modern distro installers will try to enable DMA. It makes the install process a lot faster. Some hardware doesnt like this (its pretty rare however) which is why if you pass the kernel option nodma (I think thats it. Dont quote me) then it wont try enabling DMA and it'll install fine. Your blaming the kernel developers when you just didnt RTFM.
Did you notice where I suggested Linux has lots of workarounds for resolving problems? When I said it was a DMA issue, that diagnosis was from having corrected the issue, sort of. I was able to get both systems to work under 2.6 (albeit with glacial performance, far worse than the Win 2K install) by turning DMA off. Part of the reason it was hard to figure that out was that the same hardware worked fine with DMA on under kernel 2.4 (the same way some people report that hardware that works fine with Windows 98 doesn't work correctly under newer versions).
If you must know: there seems to be a change in the rewrite of the PIIX driver in the 2.6 kernels that causes problems for some subset of people who have older computers based on the 440BX motherboard chipset; I'd direct you to this handy meta-note: http://lists.debian.org/debian-kernel/2006/10/msg0 0505.html where you'll find the following statement and many additional references should you wish to spend some time RTFM'ing:
"This is *not* a hardware problem or a CD problem. This problems has been replicated on different hard disks and on another similar computer...So far I have found it in Ubuntu and Debian distributions. Other MS OS's work fine on these computers...I suspect that it may be related to the Debian support of the southbridge PIIX4 chipset and/or the Intel 440BX and 440LX AGPset."
Here's a complete example of what I was suggesting to my parent post: here's an entire class of older machine that used to be very popular and that work perfectly under many Windows variants, but that plenty of people have reported issues with under recent Linux releases. There is very little difference between this and the Vista situation. The idea that Linux works better on old machines than Windows, especially if the install is done by someone who isn't going to RTFM and find all these little parameters you can tweak, is certainly debatable, and it takes a lot more evidence than "that's what I found" from one person to support such a statement.
The only blame that needs to be assigned here goes to whoever is responsible for you not learning where "your" supposed to put apostrophes at.
Most Linux drivers are in the kernel to begin with so unless you have exotic hardware you never need to recompile kernel modules.
I never said that I was rebuilding kernel modules with each new Linux release, but someone sure is because it has to be done with each release. My suggestion was that I doubt the main kernel developers are prioritizing new code based on backward compatibility tests with ancient hardware any more than Microsoft is.
Linux, however, it a lot more likely to actually get the OS installed, detect the hardware, and give you a usable system. I suspect MS probably puts less effort into making sure that quirks in old hardware are taken into account, as seen by the crashing installer of XP and 2K on it.
Yours is anecdotal evidence based on a pretty small sample size; I wouldn't draw such broad conclusions from such little data.
I can easily extrapolate exactly the opposite conclusions with a similarly limited experience. In the last six months, I've done two Linux installs on PCs from that same era (approx 400MHz P2) that were happily running Windows 2000. The theory was that even though they were too slow for Windows use I could recycle them into small servers. The Linux installed locked up hard either during installation or on first boot. In both cases, it turned out there was a problem with enabling DMA on these systems that caused the IDE driver to lock-up hard. I noted that both machines worked perfectly well with the older 2.4 Linux kernel.
I don't think the Linux developers working on the latest 2.6 features are paying any more attention to actually testing compatibility with ancient hardware than Microsoft is with Vista. The fact that the Linux kernel model forces drivers to be rebuilt from source with every new kernel release is different from the way Microsoft provides a stable driver API, and which model is going to get you better results with a random old piece of hardware is very unpredictable. The main advantage for Linux in situations like the one I ran into is that the problem was more transparent, and there are many more workarounds to try and resolve issues when they come up. I would hesitate to generalize on this subject beyond that.
Hypothetically, these people might well *want* to buy a lower gas mileage car, but can't because the car companies are preventing such a thing from coming to market.
Gee, I must have just imagined that I passed a Toyota Prius while I was out today. This whole wild conspiracy by the car companies idea might have been slightly defensible in the 70's, but doesn't even make sense in the current global economy. For that to happen, you'd need the US, Japanese, and German car makers to all be in on it. Do you really think the bigwigs at all those companies are working together to keep inventors down? Give me a break. They'd love to take money from the oil companies (you could charge a hell of a lot more for a car that didn't require gas), and if one of those companies came across a useable replacement technology, they'd rush it to market to crush their competition abroad.
What pisses me off the most about this suit and leads me to call hypocrite on them is that it's happening in California. If you take a look at the extreme car culture there, epitomized by the LA freeway rush hour, it's obvious the priorities of the residents there are causing the pollution. They don't have to live in nice houses far away from the city they work in and commute by car every day, but that's what they like doing. Everyone involved in this suit should spend some time in New York or London to see how you can run a big city without everyone travelling by car instead of wasting everyone's time in the courts.
My kill-a-watt has two 6' extension cords attached to it I never disconnect. When I want to measure a device, I unplug it, insert that loop, and I'm done. 6' is plenty of cord in most situations to allow you to move the meter to a comfortable reading position, while not being so much that I worry about adding significantly to the power draw. Unless your device is actually in the dark, there is no need for a flashlight, contorting to read the meter, any of that stuff.
That leaves the only real drawback at not being able to retain results or record them automatically. In most cases (idle power of computers, TVs, stereo equipment, that sort of thing) I get everything I want to know in a minute or two anyway so it doesn't matter. In a home situation, it's only for appliances like refrigerators and air conditioners that alter their consumption over time where you need something more than the instant readout, and the cumulative mode of the kill-a-watt works fine for that. I built a little spreadsheet that turns the K-a-W readings into $ based on my local electrical rate, and it took me all of 30 minutes to break down the parts of the monthly electric bill I could measure with it besides the refigerator; that I just measured overnight (to include an ice-making cycle or two) and then I was done.
Since I was already using fairly energy efficient PCs (by virture of not buying any of the pigs released the last few years and having all LCD monitors), it turned out that everything in the place was a minor expense compared to the one thing I couldn't measure directly, the heating/AC/stove gas and electric. Getting a better thermostat capable of fine adjustments based on the time of day and syncing that to the schedule here was the only thing that even had a hope of making a significant dent in the bottom line here. I did walk away from the exercise with a new-found respect for turning off the TV when I wasn't watching it.
Lower-level courses are "taught" in giant halls where ethereal profs tend to cater to students who already knew the material before they got to high school
You had professors who taught by showing dumps from ethereal? That's hardcore.
That's a pretty good bargain; $2.50 is less than the going rate I used to pay to have people attend boring classes for me and take notes. I think two slices and a soda was my average trade. As this was tech school, in many cases the instructors lack of ability to explain the material (these men were paid to get research grants, not explain things to students) meant that actually attending the lectures would leave one more confused than had you missed it and just read the book instead. Still needed somebody to go in order to figure out which sections would be tested.
Even for people who actually do show up for class, having a version of the lecture you can rewind and mull over at your leisure has a significant value. This is especially true for slower students, like the communications majors this guy is selling to.
Actually you could do this just fine with recursion. So while his solution was shit, your answer was too.
Using recursion allocates memory at run-time out of the stack space to hold the string; that solves the thread issues, but doesn't meet the stated design requirement. If we're going around labeling things as shit, clearly your reading comprehension must join that list.
This reminds me of my worst interview ever. It was for a C programming job, ten years ago. The main programmer at the company asks "how you can write a function that [some operation on an arbitrary string requiring memory] without allocating memory at run-time inside the function?". I said "you can't without relaxing some part of the requirements". He disagrees; I ask for his solution. He shows a function using a static buffer, so the memory is allocated at compile time. I point out that a) this puts a limit on the size of strings it can handle, which he accepts and b) you'll be screwed the minute you introduce that code into a multi-threaded environment like the one they deploy their code into, because your static variable will inevitably get clobbered one day by two calls to this utility function. After some argument, he comes to recognize my point, and I ultimately got offered the job.
Three months later I was fired for arguing with him all the time about how code should be built.
Slashdot Mirror
A single announcement wouldn't be used that way on it's own, it's simply a way to condense a text announcement down to [an indicator]...The genetic algorithms which give too much or too little weight to the announcements will predict badly and fail to thrive.
I guarantee you that if you put some serious time into this approach, you'd discover that the weight of any "announcement tone" indicator would end up so close to 0 that computing it in the first place would be a waste of time. Here's a better indicator: watch what the price of the stock does for the first few seconds the market is open after the announcement. Whatever direction it moved in, there's your answer for whether the announcement was good or bad from the perspective of stock price. If you put those two indicators in a genetic optimizer cage max, the fancy sematic news-reading approach is going to be left in a puddle of blood every time, squashed by a stupid but very strong indicator whose sole mantra is "the market moves the way it moves".
So a revision upwards should be more likely to bump a stock than to tank it (though it might be a close thing).
Market theorists love to point out with much amusement that a lot of things that seem like they would be strongly associated with a clear move in one direction turn out, after you analyze them properly, to be close to 50/50 that you can't trade on them usefully.
It seems like first impressions would matter a lot in such cases. You know, simple metrics like "increased earnings == good", "layoffs == outstanding", "merger == cha-ching", "merger with layoffs == do-money-dance"...A basic system seems like it would have a better chance at predicting knee-jerk movements rather than the ones resulting from a few more moments consideration.
Let me pull apart one of those as an example. If you watch a few of them, merger announcements usually have a strong impact on both companies involved. Even people have a hard time distinguishing whether a buy-out of a company is a bargain, or a big overpayment relative to the true value of the company. With the same big news announcement, one company's stock will go up, and the other's will go down, all based on the perception of whether the terms of the merger gave one party a better deal than the other. So we have one annoucement, which is likely to increase the price of one stock and decrease the other; it's a very complicated thing to predict.
And how the market will react to layoffs is dramatically more complicated even than that--layoffs as a cost-cutting measure might be good for the price, layoffs because the business is dying might kick off a gigantic selling spree, and the price can jerk around all over as big-name analysts weigh in with their opinion over the days that follow the initial news release.
I went through this whole excercise myself for a while, trying to get a computer to parse the news and do something useful with it. Turns out, there's a much easier way to figure out whether the market views something as good or bad news: just watch what the price of the stock does. You'd be far better off learning some of the techniques of technical analysis than bothering trying to understand whether the tone of a news pieces is good or bad. It would take years of training a sematic-based approach before it had any hope of being better than an approach that just looks at a few minutes of where the market is moving and assuming it's going to move in that direction more; a simple moving average crossover technique works just fine for that.
If you have a giant set of data, and you set a computer on it for long enough, it should be able to come up with some rather solid paterns/corelations/etc.
.com boom work in today's market? How well would one trained on the .com bust work? Pretty bad, right? Well, guess what...you never know which type of market you're in, and the market is constantly changing. Now you're thinking "then just train against enough data that you've seen everything"...ha! Do you think that today's market, with tons of electronic trading at very low prices, move exactly the same as the ones from the 70's where individual trades costs hundreds of dollars to execute? You can either have a small amount of data that reflects how the market is working recently, or a large amount of data that's mostly about a market that doesn't work the same way the current one does; it's impossible to get a lot of data on how the current market moves, because the current market only exists a tick of data at a time.
h tml as an initial bit of food for thought; a search on curve fitting in trading systems will lead to many, many more article on the subject of why having the computer just look for patterns on its own is of extremely limited value.
If by "solid" you mean "tradable" then no, it won't. It will produce what trading system developers refer to as a curve-fit trading system. When exposed to new market data, that type of system really doesn't work well at all.
Think about this for a minute...how well would a trading system trained on data about the
People who actually build useful systems start with a theory about how prices move, then write code to analyze the market to see if that strategy is tradable. I would suggest you read an article by well-known traders William Eckhardt and Richard Dennis at http://www.visoracle.com/swingtrend/optimization.
The same algorithm could be used to classify any news article as good or bad for a particular stock by looking at the direction the stock takes after the news appears. You could even train the classifier automatically by looking a couple of days in the past. Simply classify every single financial announcement against every single stock, eventually it'll get to the point that the classifier will be able to say that an announcement is 80% probably good news for this stock, 92% bad news for that stock.
If you ever tried to build such a system you'd realize the problem is exactly as hard as predicting the motion of the market as a whole. Market participants are working with earning estimation at a higher level than any current generation AI could possibly understand. Read up a bit on whisper numbers to get a feel for the challenges here. You could have an earnings report that says "earnings are up, we just increased sales, and we rule!" that doubles the price of one stock, because no one was expecting that. Meanwhile, the exact same report from another company tanks the price because people had driven the price of the stock up before the news in anticipation of even better numbers.
One trade I went through this with stands out in my memory. I had what I thought was juicy new information about recent sales trends for a company, and I purchased many shares before their earnings report expecting that sales were going to be up 40% from the previous quarter. Sales were actually up 50%. The next morning, as the market opened, instead of counting my profits I discovered the stock had dropped 15% after the announcements. Turns out, people with much better information than me had driven the price up over the previous few weeks in the expectation that sales were actually going to be up 70%. The notion that you can compete with this sort of behavior after the news announcements has come out is at best a wonderful fantasy; at worst, you'll actually try to do it and get crushed.
[Note: the following example is based on my understanding of the stock market, which is most likely wrong]
Completely, but it's good that you know what you don't know--you'd lose a lot less money trading that way. It's impossible to parse stock news and figure out if it's good or bad. Using your example, if Google announces that it will exceed its previously projected earnings, it's just as likely the stock will crash as skyrocket. This is because market participants are working with earning estimation at a higher level than any current generation AI could possibly understand. Read up a bit on whisper numbers to get a feel for the challenges here.
Regardless, the notion that you as an individual could possibly get news and act on it faster than the people that really move the market around is naive anyway. Many of these announcements are made outside of trading hours, and after-hours trading is difficult for an individual to do. By the time the regular market opens up again, the big move is already done.
At some point oracle should take a look at their own legal standpoint and community reputation (if Larry Ellison cares about that).
He doesn't.
Dozens of bloggers and community members are already calling it a failure
He also doesn't care about what people named Mookie or BS think, either. Whether it's a failure or not will come out on Oracle's next quarterly report, or maybe a few after that; you can't rule out the possibility that this is a loss-leader aimed at expanding Oracle market share. Every dollar that isn't paid to RedHat could be used to get a Oracle product instead.
Here's what I got out of your links, which were quite helpful with facts but slightly fuzzy with their conclusions from where I sit:
1) Oracle's Linux is at the moment a slightly broken copy of CentOS, and shouldn't be bothered with yet. I don't think this really matters. The people Oracle wants to sell this product to aren't the kind to install the first release, anyway; my guess is that what the bloggers are being used for is product beta testing, which they seem happy to help out the company with.
2) RedHat couldn't deliver a product this cheap on their scale of operations. So what? That doesn't answer whether or not Oracle can leech their work, re-skin it (either directly or indirectly), and then sell it at that price with the economy of scale their enormous operation has. You can bet that Oracle execs are world-class experts on how to manage a tech support operation in a way that keeps costs under control, lessons RedHat certainly didn't have a mature view of yet during the time period discussed by your second link.
This whole thing is just posturing right now; I'm going to wait until at least the second major revision from them before making premature judgements.
SMART has a mechanism for the drive makers to indicate what is and isn't a "failing" value for a particular attribute. If n bad sectors is enough to cause concern, then the drive should have said it was failing!
There's still a chicken/egg situation with SMART right now that makes this all more difficult. There are zero mainstream operating systems that have useful SMART software embedded in them. The smartmontools package for Linux works better than anything else I've found, but as you point out it's not exactly obvious what you should do with it and the drives don't handle it themselves correctly. I've spent a lot of time looking for a Windows SMART client that gives me useful results and found zero that do everything I want (I'm still evaluating whether the Windows smartmontools port can be turned into something useful, so far no success). On Mac OS, Apple gives you a report if you run Disk Utility, but not otherwise; there is free tool available to automate that, but even then I don't believe is running a self-test the way that's really needed. And no matter what you're doing, you're not going to get SMART data over USB, and you probably can't get it over Firewire either.
Beyond the brain-dead "SMART failure" notice that come up in some PC BIOSes, hard drive makers are hard pressed to find any software that actually uses SMART with a big enough client base to make it worth testing. Is it any wonder that they fail to implement all the interfaces required to make their drives emit errors robustly? There is zero market pressure from the major upstream software or hardware vendors buying hard drives for drive manufacturers to care.
What bothered me about your initial message was the implication that because SMART data is difficult to interpret, and therefore far from automatic in its current state, that it wasn't of any value. The data is hard to work with, but it does work far better than nothing--and in your case it appears your drive was giving evidence it was dying well before it really failed completely, you just weren't interpreting that correctly. As for what's wrong that it doesn't work automatically, so that we all have to become experts on interpreting SMART errors, I wouldn't place blame at the feet of the drive manufacturers for not labeling failure points correctly; there isn't enough software that reads them for that to be an important feature to implement. The right question is what it would take to have users start screaming in unison for operating system vendors to include a robust, automatic SMART check in their software by default.
Second that. The new all-you-can-eat plan from Safari has saved me a fortune in book buying, and I have to lug a lot less stuff around to be productive as well.
From your link:
"I ran smartd, and occasionally took a look at the statistics with smartctl, to make sure nothing was going wrong. I had a few reallocated sectors, but nothing to cause concern."
Stop right there--"a few reallocated sectors" is always a cause for concern. Maybe not during the first month or two, but if that number is growing after the inital break-in period you should consider the drive extremely suspect. As you'll see many people in this thread comment, reallocated sectors is the #1 thing to watch for to determine when a drive is failing. I wonder whether you had smartd.conf setup correctly if that number was going up and you weren't getting warnings screaming that the drive was going bad.
Regardless, I fully support your backup-urging bell ringing, as you can never be too paranoid there, and would drop some change in your jar were I to pass you on the sidewalk.
A typical configuration for the smartmon-tools package for Linux will run a full SMART self-test every day. That test has caught three hard drive failures in the last three years for me (two Maxtors, one Seagate), all of which started screaming before any data was lost. In one of the Maxtor cases, the drive went down in flames so fast after the initial warning that I lost some data, the other two gave me enough time to make (another!) backup before tossing or RMA'ing the drive.
I have considerably less faith in any of the Windows based SMART monitoring tools, as I haven't found any that seem to run an equally rigorous test on the drive every day. As you suggest, unless you run a good test, the drive is unlikely to generate useful SMART errors until it's too late. You can go crazy staring at the low-level statistics trying to figure out whether changes in the rate of the error rates there mean anything, but when the self-test reports an error that drive is done. For me, that's been early enough to be helpful while not causing me to toss the drive before it's truly worn out.
I received both a BS and an MS in computer science at Stevens Institute of Technology back in 1993. Most of the classes people are suggesting here were all required to earn the undergrad degree there; in addition to 3 semesters of Calculus, you also had to pass discrete mathematics, statistics (two semesters of that), and linear algebra as part of the standard program.
Out of the required math classes, two stood out as being particularly helpful for my career in software development. The introductions to logic, graph theory, proof, and other topics in the discrete math course were absolutely vital to understanding more complicated computer science constructs. I recall trying to understand how compilers were built before that time and being completely confused, but everything made perfect sense after completing that class.
The other class was in operations research, a subject I didn't notice anyone bringing up here yet. OR really made an impression on me as it provided a bridge for how to apply several types of mathematical approaches that had seemed completely theoretical to solving the kinds of real-world problems computers are good at helping with. As the most obvious example, I feel that having a solid practical understanding of how to model a complicated queue or flow across a series of queues is wildly more useful for building software than anything related to big-O analysis will ever be, unless you're one of the rare people writing basic algorithm libraries. My experience is that you'll see dozens of messaging queue issues in business software design for every problem that requires an understanding of complexity analysis. And learning how formally construct decision trees turns into a great tool when you get far enough along that you're managing projects instead of just working on them. I considered it unfortunate that I didn't discover this class of mathematics until very late into my time at school, as I would have gladly taken more of it and benefitted from--something I can't say about statistics or linear algebra, where I felt the basic introduction gave sufficient understanding for normal programming tasks.
Most modern distro installers will try to enable DMA. It makes the install process a lot faster. Some hardware doesnt like this (its pretty rare however) which is why if you pass the kernel option nodma (I think thats it. Dont quote me) then it wont try enabling DMA and it'll install fine. Your blaming the kernel developers when you just didnt RTFM.
0 0505.html where you'll find the following statement and many additional references should you wish to spend some time RTFM'ing:
Did you notice where I suggested Linux has lots of workarounds for resolving problems? When I said it was a DMA issue, that diagnosis was from having corrected the issue, sort of. I was able to get both systems to work under 2.6 (albeit with glacial performance, far worse than the Win 2K install) by turning DMA off. Part of the reason it was hard to figure that out was that the same hardware worked fine with DMA on under kernel 2.4 (the same way some people report that hardware that works fine with Windows 98 doesn't work correctly under newer versions).
If you must know: there seems to be a change in the rewrite of the PIIX driver in the 2.6 kernels that causes problems for some subset of people who have older computers based on the 440BX motherboard chipset; I'd direct you to this handy meta-note: http://lists.debian.org/debian-kernel/2006/10/msg
"This is *not* a hardware problem or a CD problem. This problems has been replicated on different hard disks and on another similar computer...So far I have found it in Ubuntu and Debian distributions. Other MS OS's work fine on these computers...I suspect that it may be related to the Debian support of the southbridge PIIX4 chipset and/or the Intel 440BX and 440LX AGPset."
Here's a complete example of what I was suggesting to my parent post: here's an entire class of older machine that used to be very popular and that work perfectly under many Windows variants, but that plenty of people have reported issues with under recent Linux releases. There is very little difference between this and the Vista situation. The idea that Linux works better on old machines than Windows, especially if the install is done by someone who isn't going to RTFM and find all these little parameters you can tweak, is certainly debatable, and it takes a lot more evidence than "that's what I found" from one person to support such a statement.
The only blame that needs to be assigned here goes to whoever is responsible for you not learning where "your" supposed to put apostrophes at.
Most Linux drivers are in the kernel to begin with so unless you have exotic hardware you never need to recompile kernel modules.
I never said that I was rebuilding kernel modules with each new Linux release, but someone sure is because it has to be done with each release. My suggestion was that I doubt the main kernel developers are prioritizing new code based on backward compatibility tests with ancient hardware any more than Microsoft is.
Linux, however, it a lot more likely to actually get the OS installed, detect the hardware, and give you a usable system. I suspect MS probably puts less effort into making sure that quirks in old hardware are taken into account, as seen by the crashing installer of XP and 2K on it.
Yours is anecdotal evidence based on a pretty small sample size; I wouldn't draw such broad conclusions from such little data.
I can easily extrapolate exactly the opposite conclusions with a similarly limited experience. In the last six months, I've done two Linux installs on PCs from that same era (approx 400MHz P2) that were happily running Windows 2000. The theory was that even though they were too slow for Windows use I could recycle them into small servers. The Linux installed locked up hard either during installation or on first boot. In both cases, it turned out there was a problem with enabling DMA on these systems that caused the IDE driver to lock-up hard. I noted that both machines worked perfectly well with the older 2.4 Linux kernel.
I don't think the Linux developers working on the latest 2.6 features are paying any more attention to actually testing compatibility with ancient hardware than Microsoft is with Vista. The fact that the Linux kernel model forces drivers to be rebuilt from source with every new kernel release is different from the way Microsoft provides a stable driver API, and which model is going to get you better results with a random old piece of hardware is very unpredictable. The main advantage for Linux in situations like the one I ran into is that the problem was more transparent, and there are many more workarounds to try and resolve issues when they come up. I would hesitate to generalize on this subject beyond that.
See http://www.skepdic.com/pareidol.html for a definition. A commentary on this particular image (along with some wicked cool visual illusions) is at http://www.michaelbach.de/ot/fcs_face_on_mars/inde x.html
Please excuse me, I have to return to searching my toast for the Virgin Mary now.
they should make being a smug materialist illegal as well
But when cases went to court, where in California would they find 12 people who aren't smug materialists to serve on the jury?
Hypothetically, these people might well *want* to buy a lower gas mileage car, but can't because the car companies are preventing such a thing from coming to market.
Gee, I must have just imagined that I passed a Toyota Prius while I was out today. This whole wild conspiracy by the car companies idea might have been slightly defensible in the 70's, but doesn't even make sense in the current global economy. For that to happen, you'd need the US, Japanese, and German car makers to all be in on it. Do you really think the bigwigs at all those companies are working together to keep inventors down? Give me a break. They'd love to take money from the oil companies (you could charge a hell of a lot more for a car that didn't require gas), and if one of those companies came across a useable replacement technology, they'd rush it to market to crush their competition abroad.
What pisses me off the most about this suit and leads me to call hypocrite on them is that it's happening in California. If you take a look at the extreme car culture there, epitomized by the LA freeway rush hour, it's obvious the priorities of the residents there are causing the pollution. They don't have to live in nice houses far away from the city they work in and commute by car every day, but that's what they like doing. Everyone involved in this suit should spend some time in New York or London to see how you can run a big city without everyone travelling by car instead of wasting everyone's time in the courts.
The only way I would accept this suit as being appropriate is if everyone involved in this case rides a bike or walks to work.
My kill-a-watt has two 6' extension cords attached to it I never disconnect. When I want to measure a device, I unplug it, insert that loop, and I'm done. 6' is plenty of cord in most situations to allow you to move the meter to a comfortable reading position, while not being so much that I worry about adding significantly to the power draw. Unless your device is actually in the dark, there is no need for a flashlight, contorting to read the meter, any of that stuff.
That leaves the only real drawback at not being able to retain results or record them automatically. In most cases (idle power of computers, TVs, stereo equipment, that sort of thing) I get everything I want to know in a minute or two anyway so it doesn't matter. In a home situation, it's only for appliances like refrigerators and air conditioners that alter their consumption over time where you need something more than the instant readout, and the cumulative mode of the kill-a-watt works fine for that. I built a little spreadsheet that turns the K-a-W readings into $ based on my local electrical rate, and it took me all of 30 minutes to break down the parts of the monthly electric bill I could measure with it besides the refigerator; that I just measured overnight (to include an ice-making cycle or two) and then I was done.
Since I was already using fairly energy efficient PCs (by virture of not buying any of the pigs released the last few years and having all LCD monitors), it turned out that everything in the place was a minor expense compared to the one thing I couldn't measure directly, the heating/AC/stove gas and electric. Getting a better thermostat capable of fine adjustments based on the time of day and syncing that to the schedule here was the only thing that even had a hope of making a significant dent in the bottom line here. I did walk away from the exercise with a new-found respect for turning off the TV when I wasn't watching it.
Lower-level courses are "taught" in giant halls where ethereal profs tend to cater to students who already knew the material before they got to high school
You had professors who taught by showing dumps from ethereal? That's hardcore.
That's a pretty good bargain; $2.50 is less than the going rate I used to pay to have people attend boring classes for me and take notes. I think two slices and a soda was my average trade. As this was tech school, in many cases the instructors lack of ability to explain the material (these men were paid to get research grants, not explain things to students) meant that actually attending the lectures would leave one more confused than had you missed it and just read the book instead. Still needed somebody to go in order to figure out which sections would be tested.
Even for people who actually do show up for class, having a version of the lecture you can rewind and mull over at your leisure has a significant value. This is especially true for slower students, like the communications majors this guy is selling to.
If you look at benchmarks comparing the two, the 6800GT performs essentially the same as the later 6800GS.
The review at Anandtech includes benchmarks against cards going back to the 6600/6800 era.
Actually you could do this just fine with recursion. So while his solution was shit, your answer was too.
Using recursion allocates memory at run-time out of the stack space to hold the string; that solves the thread issues, but doesn't meet the stated design requirement. If we're going around labeling things as shit, clearly your reading comprehension must join that list.
This reminds me of my worst interview ever. It was for a C programming job, ten years ago. The main programmer at the company asks "how you can write a function that [some operation on an arbitrary string requiring memory] without allocating memory at run-time inside the function?". I said "you can't without relaxing some part of the requirements". He disagrees; I ask for his solution. He shows a function using a static buffer, so the memory is allocated at compile time. I point out that a) this puts a limit on the size of strings it can handle, which he accepts and b) you'll be screwed the minute you introduce that code into a multi-threaded environment like the one they deploy their code into, because your static variable will inevitably get clobbered one day by two calls to this utility function. After some argument, he comes to recognize my point, and I ultimately got offered the job.
Three months later I was fired for arguing with him all the time about how code should be built.
I'm glad Microsoft is finally introducing a product in this space, because they're the company I look to for reliable and secure software.