I can sympathize with not wanting to be a Java programmer in the enterprise space. Perhaps that's what makes the prospect of programming seem boring to her.
Different programming languages involve different thought processes, and work better in certain domains than others. If she's retooling anyway, perhaps she should look at other languages. I'm not sure what's hot in the Spanish job market at the moment, but perhaps looking for job listings from the type of company or organization she'd like to work for would give a hint as to what language to learn. If you want a few generic recommendations, then the ubiquitous Javascript (some modern style, not going to advocate for or against a specific framework or library), or the JVM centric Scala, or the niche-pervasive Python come to mind.
I'm going to avoid the sweeping generalizations about gender that seem to epidemic, and just suggest that the focus should be on the organization and problems to be solved, and not on the technology. If you like those, the job has potential to be interesting - and if the organization is any good, they'll have chosen a language that fits their problem space well.
In the bad old days, when there was another antisocial behavior that profoundly affected the innocent victims in adjacent seats, we divided the plane into smoking and non smoking sections. There was leakage from section to section, but at least it wasn't in your face.
Many Amtrak trains have a highly desirable "quiet car",which helps to separate those the see the trip along the east coast as a continuous sales call opportunity from those that see the trip as a continuous concentration or sleeping opportunity.
So, I'm all for allowing calls on planes, provided I can book a seat in the STFU section for no extra cost. Especially if it saves me from taking a transatlantic flight surrounded by a gaggle of teenagers that think it's a Beatles concert and not a redeye.
350k telephone operators (who provided a service appreciated by the people they spoke to) in 1940 with a US pop of ~ 132m. 408k combined telemarketers and call centers (who provide a service widely reviled and high stress) in 201x with a US pop of ~ 308m.
Not more jobs, fewer. 50% fewer population adjusted.
Indy bookstores up from 1,401 in 2009 to 1,632 today. The final Border's closing wave? 399 stores. That's fewer jobs in bookstores, not more. Might be better jobs in this case.
Technology absolutely kills jobs, and kills careers. It also creates new jobs and new careers, but not necessarily for the people that lost their jobs. The fallacy comes from pretending that all jobs are equal and can be subsumed into a single total job count.
Doesn't mean I want to live like a Luddite, however. But TFAs above are rather thin on reasoning.
Seems like the answer is pretty simple to me: Verizon customers should send them a check until they drop this policy. Note that I didn't say "drop your online payment option and send them a check." Simply send them a check, for a little bit too much, a week before your automatic billing date. They can sort out how to handle the expense of processing all of those checks, plus cancelling (or reversing, even better) the automatic payment for that cycle, deal with the trivial credit balances on the account, and generally be miserable. If they charge you automatically with the service fee, complain that the service was already paid for. If you and 10,000 of your closest friends do this, the policy will change in one month. If they refuse your alternate payment in any fashion, call your state attorney general, the BBB, enterprising consumer reporters, and the rest of the usual suspects.
Or just shrug and go along with it as most consumers do, which is why this is a smart move for Verizon. Wait until you get a "wire maintenance fee" for the charger on your cell phone.
If you're going to spend $700 on a video card, you'll probably spend on monitors too, especially since monitors tend to have a longer usable life cycle than video cards.
Show me free software/free drivers running four to six physical displays with full 3d acceleration. Let me choose whether it's a single desktop with one logical display, a single desktop with multiple logical displays, or multiple desktops. While I'd personally prefer GNU/Linux of a Debian flavor, ship it for any open environment you want, we'll take care of the rest.
Ship this software environment at the same time you release the card. Betas and patches are fine. Yes, that means collaborate in advance, and leave behind the last vestiges of pretense about competitive advantage via secrecy. Marketing, do-not-discuss-before-date NDAs are fine. Withholding the engineering data that will eventually be public anyway is counterproductive.
Parent post got part way there - yes, the web and HTML is a great way to deliver content.
However, the key here is what _software_ the students will be expected to run in order to _author_ content.
For those of you Windows zealots that haven't bothered to try a Mac, please be aware that it's perfectly possible to run MS Office. But it's also possible to run Apple's iWork suite, or OpenOffice. Or Google Apps in the browser.
It's very common for IT departments in all types of organizations to choose to support a single OS platform. It's equally common for competent power-users in those organizations to opt-out and use the platform of their choice - but to take on the responsibility of self support. Those policies are usually written in draconian tones "we only support X, you must use X" - but in practice it's easier to keep the power users occupied self-supporting their unapproved platforms than have them hacking away at your standard ones.
The thing that makes or breaks this situation is the software platform chosen. I'd be a lot more concerned about requirements to submit classwork in native Pages (the iWork word processor) format than I am the choice of official supported hardware. If the software and data formats are reasonably compatible with multiple platforms, things will work out.
It's fine for them to choose a supported platform. It's not fine for them to make it gratuitously difficult for others to self-support. If a group of determined parents and students want to use Linux environments instead, it should be possible - not supported, but possible. Similarly if they want to have a Windows group, so be it. This school hasn't made the mistake of blocking this - yet, or at least according to the data available to us.
Now, for those who haven't actually laid hands on a MacBook side by side with an equivalently equipped other laptop, you really ought to do so before asserting the value for your dollar spent. Heck, run Linux on both for a week, taking the OSX out of the equation, and see what think. It's premium hardware, and sometimes that's worth it and has a lower TCO. Looking only at the initial purchase price is foolhardy.
TFA says that cows walk around 8 hours a day grazing anyway.
Let's get to the more important questions: What impact does all that captive exercise have on the tasty dairy and beef products so critical to maintaining our waistlines and thickening our arteries?
If it makes the beef even better and generates power, it's a total win.
(With unheartfelt apologies to the veg types in the crowd).
Ah, the Altos systems. 8800 series, then 486, then 586. They used up numbers years before Intel got to them (the Altos 486 had an Intel 80186 in it, and 4 serial ports). Often paired with Wyse terminals. Anybody else remember "business basic"?
It's almost certainly an ST506 drive; you will be very hard pressed to connect it to a PCI era system; probably can only get as far as AT bus machine.
In any case, if you do manage to image the drive, the filesystem will be based on either Unix version 7, Unix System V, or the Berkeley Fast File System. It wasn't until Linux rolled along that we started to seriously fork into lots of file system variants. It's most likely the basic System V file system, which is well documented, and pretty simple stuff.
The posters above are correct, however. You really should try the serial port approach first. I'd go for cu over uucp - getting uucp running can be quite an exercise in itself. And you'll want either tar or cpio; probably tar, but watchout for version and format incompatibilities there as well.
You can also just cat the data out a serial port, and capture it as a session log on the other end. That's likely to be the easiest solution, and perhaps more reliable than any other.
You haven't said what the nature of the data is, but after this much time laying dormant, you are likely to have substantial challenges at the application level interpreting the data as well.
Right direction, but not far enough. I'm thinking that custom made tuxedos are the way to go here, with company paid dry cleaning. Of course, each employee is going to need a closet full, ala Men in Black.
As a bonus, on bad days you can pretend you're in the Matrix.
To continue in that vein, exactly which consumers "loved" Microsoft's products? They were bundled in with the machine choice, and they weren't an explicit brand choice. Do consumers "love" the tires that come with their cars?
We tolerated Microsoft's products (intially), because they were essentially "free", especially by comparison to the alternatives, which in those days were minicomputer OSes, and CP/M. We didn't pretend that they were innovative or even close to technical parity. Go look at the DOS 3.3 API. Or 2.1.
So close! Just not enough emphasis on the "Unfortunately it was ActiveX based" part. The model in vogue at the time had web applications interacting with downloaded controls. In one camp was ActiveX, in the other was java and Applets. Anybody remember Applets? Remember J++?
There were actually many commercial sites out there doing AJAXy kinds of things, but usually just to funnel data to and from ActiveX controls, which were, of course, Windows and IE only. So the early failure of AJAX was linked to the failure of an overall Microsoft embrace and extend tactic for web applications. It was a good effort, and they almost made it work. Had online banking taken off a little more quickly, we might all be using an IE only web today.
Fortunately, it didn't work, and AJAX (as well as downloaded controls) went into dormancy until actual cross-platform techniques were evolved. It was the monoculture(s) that killed the early AJAX stuff.
I suspect that the next push after alternative scripting languages to javascript will be back on the downloaded controls front. This time around, though, candidate solutions will have to work in all browsers.
You miss the point. It's not Google's bandwidth supplier that's the problem here. It's *YOUR* ISP. They say to Google: Hey - we have a million users, unless you pay us $X, they'll get 1Kbytes/second to Google and 1Mbytes/second to Yahoo. There is no "somewhere else" that Google can go to. Since the ISP's that get their funding this way will be able to charge their end users less, you'll start to see lower cost (to the consumer) ISP's popping up who get their funding from the sites they provide high bandwidth to.
Who loses? Well, anyone who uses Wikipedia for example. Will Wikipedia be able to pay the top 100 ISP's a few million dollars a year? Certainly not. So you'll find that access to Wikipedia will be dog slow from these low cost ISP's and access to "insert soul-sucking megacorporation here"'s encyclopedia will be fast...albeit advert laden.
I think you've moved too quickly here in your assumptions. Are you assuming that Google and Yahoo will pay, or won't pay? Let's play the scenario out a bit:
There are a relatively small number of large players that would make up the bulk of this proposed revenue stream to the ISPs. Google, Yahoo, EBay, Vonage(*), MSN, etc. Interestingly enough, that lists starts to look a lot like a list of "destination sites" - the type of site that motivates people to get an ISP in the first place. These sites also have a large enough public profile that their press releases can saturate the media. If a sufficient number of these sites (X) refuse to pay, and if a sufficient number of major ISPs (Y) choose to not implement discriminatory service, then those ISPs that do will lose, both in public opinion and in business. And likely eventually in court.
I submit that X and Y are both suprisingly small. Now, if any major ISP chooses to do the right thing, and they happen to have any major sites as their customers, the ISP now has a very good reason to throw it's peering weight around against the misbehaving ISPs. There's one market feedback loop.
But what happens if all the ISPs go bad at the same time? That's when the government should get involved, and there are many angles based on existing law, ranging from collusion/anti-trust to removing common carrier status/busting 'em for kiddie porn. Interestingly enough, this can apply at a smaller scale for those areas of the country where there is insufficient choice of ISPs.
So I think a little saber rattling is just fine, but it is too early to consider new legislation. If the market starts going the wrong way, there's plenty of existing government mechanisms to encourage it to correct itself. I can certainly sympathize with a view that's skeptical of the executive branch's inclinations to take action, but substituting legislation is not a better answer.
(*) I think that the subcategory of sites making money off high bandwidth services like VOIP that compete with offerings ISPs make is a bit different than the relatively low bandwidth offerings of a wikipedia. I don't think there is really much risk to the wikipedia's of the world. The Vonages, OTOH, are on the front lines of a battlefield.
No, it doesn't create problems, it just isn't a silver bullet to solve them. This is the extra local knowledge requirement I stated above.
Let's take the database example that many people jump to. It's certainly correct that clustered databases are complex, expensive beasts, and so if you have an application that requires a single, modifiable (not read only), ACID compliant database image for a single site, a large iron fault tolerant solution will likely make more sense than a clustered attempt.
But what if that's not your requirement? If, for example, the majority of your application's database needs are read-only, then perhaps you can split it to a set of clustered read-only databases, and an active/passive set up for your modifyable database. You then use a publishing model for changes to your read-only cluster. This pattern is applicable to a large number of online commerce sites - you have a catalog of product information that people search in. You publish updates to this catalog relatively infrequently - a few times a day or less. You have a lot smaller volume of traffic creating new commerce accounts and invoices than searching the catalog. Notice that it's okay if the updates to the catalog aren't in dead sync across all the copies of the database for a few seconds or minutes. Once you stop thinking in monolithic single database terms, it frees you to architect a more effective solution. Local knowledge.
You mention synchronized memory access. Of course it's silly to do this across a cluster. The question becomes again: do you need it? It's not uncommon for the synced piece to be a very small fraction of the overall memory requirement. So you factor the synced stuff out into procedure calls executed against a single service somewhere running on a single box, and then you let everything else exist as multiple copies in various cluster nodes for performance. Local knowledge.
Clustering is not a drop in solution; it requires careful design all the way from power supplies to application requirements. Done correctly, however, you get Google. It's about applying local knowledge to choose the most effective long-term architecture for the job.
One final OT thought: Simple is harder than complex. Maybe the exercise of trying to model your underlying requirement as a "simple web application" would be enlightening.
Fault tolerance gets you a machine that keeps running in the face of hardware failures and maintenance. The switchover time is arguably negligible.
Clustering gets you a set of services that keep running in the face of hardware failures and maintenance. The switchover time can range from negligible to huge depending on the application involved.
However, clustering also helps you to solve other problems, including scaling, software failures, software upgrades, A-B testing (running different versions side by side), major hardware upgrades, and even data center relocations.
Clustering tends to require a lot more local knowledge to get right.
So if you narrow the problem definition to hardware only, they solve the same class of problems. But when you broaden it to the full range of what clustering offers you find a greater opportunity for cost savings - because one technique is covering multiple needs.
Every measuring unit uses kilo/mega/giga to mean powers of ten. Computer world was the odd one out, and it should rightly be labeled specifically.
Oh, the computer world uses those prefixes to mean powers of 10 too. They just mean powers of 10 in base 2 math:)
Works for me. So now a Kilobyte is 8 bytes (2^3) a Megabyte is 64 bytes (2^6), and a Gigabyte is 512 bytes (2^9)? Cool, my laptop drive now holds billions and billions of Mb. Does yours?
Could you please specify where the right place is to leave feedback? Particularly for those of us that have been burned in the past and now won't buy ATI products until or unless they release specifications or open source? Since we don't have any current products, the driver feedback page is not going to work. We represent additional customers and revenue.
if you always get a negative reinforcement for an action, operant conditioning will cause the drivers to slow down.
Nice theory, but beware unintended consequences. For example, it may train drivers to drive faster, slam on the brakes just before the measurement zone to roll through it at limit speed, then accelerate between the measurement zone and the traffic light back up to a higher speed. That would be even less safe.
(Yes, I'm going to handwave over the details. Some of you smart folks can figure out how to make this work).
Accept SMTP messages only from known senders (whitelist)
Extend SMTP to allow receipt of pointers to messages housed elsewhere. Apply blacklists to this feature.
Extend POP3/IMAP/your choice to allow one-time pickup of a message (the pointer accepted earlier) by a remote recipient.
Extend MUAs to do one time pickup, and update whitelist / blacklists. Allow application of autofiltering here if the user wants.
Why do the above? It forces the spammer to house the mail instead of the recipient. If it is a spam, there's a good chance the sending site will be blacklisted before many of the recipients ever receive it.
Not perfect, but it changes the economic balance in the right direction without payment schemes.
I agree, except that the whole point is that there is a switching cost. You tend to use the same package you used the preceding year.
As an '01 and before customer who opted not to use them in '02, I'm not switching back in '03 unless they overcome the switching costs for me - say by sending me a free copy of the equivalent products to those that I used in '01.
Sure, it won't win them back the revenue for '03, but that's already lost. It will get them some for '04 and beyond.
Please listen to the parent. Your question demonstrates that you do not have the required experience. Also, if the incoming mains are the size implied by your description, you will not have access to the correct parts to work in this box.
A hint: Nobody, and especially no professional would do work on the infeed side of a box like that with the power still on. Sliding in a new circuit into a clean space hot, sure, but revamping a box that apparently has already had an incident, no way.
This post typed with my left hand in my back pocket.
SCO stock dropped from $9 to $6 today. I'm surprised it closed that high.
There wasn't enough time between the start of the
freefall after lunch, and the close of the markets.
Short-sellers who didn't want overnight exposure to further lies^h^h^h^h SCO press releases probably took their profits. 24% isn't bad for a day's work. Heck, anything over 5% is well worth the effort.
Letters from lawyers are not akin to jack-booted thugs waking me up to give me your opinion. This was a legal situation, not an invitation to a party.
Nice rhetorical image. How do you know I wouldn't send a beautiful person that happened to have a loud voice?
As for PCI-SIG buying the list from him, that doesn't make sense. The PCI-SIG feels (wrongly) that such a list is unnecessary.
How do you know how the PCI-SIG feels? All evidence presented shows that they have an interest in the list.
They should buy it as a gesture of apology for being rude, and because it's in their, and everyone else's best interest. In what world doesn't it make sense?
Letters from lawyers clearly have more weight than letters from organizations, which have more weight than phone calls, which have more weight than emails, which have more weight than IMs. Surely you recognize that.
This would have become a legal situation had Jim not responded to any other attempt reach him, but he was not extended that courtesy.
Had that simple action been taken, not only would the PCI-SIG not have paid for useless legal services, they would have avoided senseless damage to their goodwill.
Humorously, I just heard George W. say "There are too many lawsuits in America!" as a quote from a speech today.
Slashdot Mirror
I can sympathize with not wanting to be a Java programmer in the enterprise space. Perhaps that's what makes the prospect of programming seem boring to her.
Different programming languages involve different thought processes, and work better in certain domains than others. If she's retooling anyway, perhaps she should look at other languages. I'm not sure what's hot in the Spanish job market at the moment, but perhaps looking for job listings from the type of company or organization she'd like to work for would give a hint as to what language to learn. If you want a few generic recommendations, then the ubiquitous Javascript (some modern style, not going to advocate for or against a specific framework or library), or the JVM centric Scala, or the niche-pervasive Python come to mind.
I'm going to avoid the sweeping generalizations about gender that seem to epidemic, and just suggest that the focus should be on the organization and problems to be solved, and not on the technology. If you like those, the job has potential to be interesting - and if the organization is any good, they'll have chosen a language that fits their problem space well.
In the bad old days, when there was another antisocial behavior that profoundly affected the innocent victims in adjacent seats, we divided the plane into smoking and non smoking sections. There was leakage from section to section, but at least it wasn't in your face.
Many Amtrak trains have a highly desirable "quiet car",which helps to separate those the see the trip along the east coast as a continuous sales call opportunity from those that see the trip as a continuous concentration or sleeping opportunity.
So, I'm all for allowing calls on planes, provided I can book a seat in the STFU section for no extra cost. Especially if it saves me from taking a transatlantic flight surrounded by a gaggle of teenagers that think it's a Beatles concert and not a redeye.
That's just the tip of the iceberg:
350k telephone operators (who provided a service appreciated by the people they spoke to) in 1940 with a US pop of ~ 132m.
408k combined telemarketers and call centers (who provide a service widely reviled and high stress) in 201x with a US pop of ~ 308m.
Not more jobs, fewer. 50% fewer population adjusted.
Indy bookstores up from 1,401 in 2009 to 1,632 today. The final Border's closing wave? 399 stores. That's fewer jobs in bookstores, not more. Might be better jobs in this case.
Technology absolutely kills jobs, and kills careers. It also creates new jobs and new careers, but not necessarily for the people that lost their jobs. The fallacy comes from pretending that all jobs are equal and can be subsumed into a single total job count.
Doesn't mean I want to live like a Luddite, however. But TFAs above are rather thin on reasoning.
Seems like the answer is pretty simple to me: Verizon customers should send them a check until they drop this policy. Note that I didn't say "drop your online payment option and send them a check." Simply send them a check, for a little bit too much, a week before your automatic billing date. They can sort out how to handle the expense of processing all of those checks, plus cancelling (or reversing, even better) the automatic payment for that cycle, deal with the trivial credit balances on the account, and generally be miserable. If they charge you automatically with the service fee, complain that the service was already paid for. If you and 10,000 of your closest friends do this, the policy will change in one month. If they refuse your alternate payment in any fashion, call your state attorney general, the BBB, enterprising consumer reporters, and the rest of the usual suspects.
Or just shrug and go along with it as most consumers do, which is why this is a smart move for Verizon. Wait until you get a "wire maintenance fee" for the charger on your cell phone.
Perhaps you could start evaluating some of these?
If you're going to spend $700 on a video card, you'll probably spend on monitors too, especially since monitors tend to have a longer usable life cycle than video cards.
Show me free software/free drivers running four to six physical displays with full 3d acceleration. Let me choose whether it's a single desktop with one logical display, a single desktop with multiple logical displays, or multiple desktops. While I'd personally prefer GNU/Linux of a Debian flavor, ship it for any open environment you want, we'll take care of the rest.
Ship this software environment at the same time you release the card. Betas and patches are fine. Yes, that means collaborate in advance, and leave behind the last vestiges of pretense about competitive advantage via secrecy. Marketing, do-not-discuss-before-date NDAs are fine. Withholding the engineering data that will eventually be public anyway is counterproductive.
Parent post got part way there - yes, the web and HTML is a great way to deliver content.
However, the key here is what _software_ the students will be expected to run in order to _author_ content.
For those of you Windows zealots that haven't bothered to try a Mac, please be aware that it's perfectly possible to run MS Office. But it's also possible to run Apple's iWork suite, or OpenOffice. Or Google Apps in the browser.
It's very common for IT departments in all types of organizations to choose to support a single OS platform. It's equally common for competent power-users in those organizations to opt-out and use the platform of their choice - but to take on the responsibility of self support. Those policies are usually written in draconian tones "we only support X, you must use X" - but in practice it's easier to keep the power users occupied self-supporting their unapproved platforms than have them hacking away at your standard ones.
The thing that makes or breaks this situation is the software platform chosen. I'd be a lot more concerned about requirements to submit classwork in native Pages (the iWork word processor) format than I am the choice of official supported hardware. If the software and data formats are reasonably compatible with multiple platforms, things will work out.
It's fine for them to choose a supported platform. It's not fine for them to make it gratuitously difficult for others to self-support. If a group of determined parents and students want to use Linux environments instead, it should be possible - not supported, but possible. Similarly if they want to have a Windows group, so be it. This school hasn't made the mistake of blocking this - yet, or at least according to the data available to us.
Now, for those who haven't actually laid hands on a MacBook side by side with an equivalently equipped other laptop, you really ought to do so before asserting the value for your dollar spent. Heck, run Linux on both for a week, taking the OSX out of the equation, and see what think. It's premium hardware, and sometimes that's worth it and has a lower TCO. Looking only at the initial purchase price is foolhardy.
TFA says that cows walk around 8 hours a day grazing anyway.
Let's get to the more important questions: What impact does all that captive exercise have on the tasty dairy and beef products so critical to maintaining our waistlines and thickening our arteries?
If it makes the beef even better and generates power, it's a total win.
(With unheartfelt apologies to the veg types in the crowd).
Ah, the Altos systems. 8800 series, then 486, then 586. They used up numbers years before Intel got to them (the Altos 486 had an Intel 80186 in it, and 4 serial ports). Often paired with Wyse terminals. Anybody else remember "business basic"?
It's almost certainly an ST506 drive; you will be very hard pressed to connect it to a PCI era system; probably can only get as far as AT bus machine.
In any case, if you do manage to image the drive, the filesystem will be based on either Unix version 7, Unix System V, or the Berkeley Fast File System. It wasn't until Linux rolled along that we started to seriously fork into lots of file system variants. It's most likely the basic System V file system, which is well documented, and pretty simple stuff.
The posters above are correct, however. You really should try the serial port approach first. I'd go for cu over uucp - getting uucp running can be quite an exercise in itself. And you'll want either tar or cpio; probably tar, but watchout for version and format incompatibilities there as well.
You can also just cat the data out a serial port, and capture it as a session log on the other end. That's likely to be the easiest solution, and perhaps more reliable than any other.
You haven't said what the nature of the data is, but after this much time laying dormant, you are likely to have substantial challenges at the application level interpreting the data as well.
Right direction, but not far enough. I'm thinking that custom made tuxedos are the way to go here, with company paid dry cleaning. Of course, each employee is going to need a closet full, ala Men in Black.
As a bonus, on bad days you can pretend you're in the Matrix.
I suppose now we'll all wear parkas and cram energy bars during our kernel compiles?
Anyone know the cost per KWH of corn syrup?
To continue in that vein, exactly which consumers "loved" Microsoft's products? They were bundled in with the machine choice, and they weren't an explicit brand choice. Do consumers "love" the tires that come with their cars?
We tolerated Microsoft's products (intially), because they were essentially "free", especially by comparison to the alternatives, which in those days were minicomputer OSes, and CP/M. We didn't pretend that they were innovative or even close to technical parity. Go look at the DOS 3.3 API. Or 2.1.
So close! Just not enough emphasis on the "Unfortunately it was ActiveX based" part. The model in vogue at the time had web applications interacting with downloaded controls. In one camp was ActiveX, in the other was java and Applets. Anybody remember Applets? Remember J++?
There were actually many commercial sites out there doing AJAXy kinds of things, but usually just to funnel data to and from ActiveX controls, which were, of course, Windows and IE only. So the early failure of AJAX was linked to the failure of an overall Microsoft embrace and extend tactic for web applications. It was a good effort, and they almost made it work. Had online banking taken off a little more quickly, we might all be using an IE only web today.
Fortunately, it didn't work, and AJAX (as well as downloaded controls) went into dormancy until actual cross-platform techniques were evolved. It was the monoculture(s) that killed the early AJAX stuff.
I suspect that the next push after alternative scripting languages to javascript will be back on the downloaded controls front. This time around, though, candidate solutions will have to work in all browsers.
There are a relatively small number of large players that would make up the bulk of this proposed revenue stream to the ISPs. Google, Yahoo, EBay, Vonage(*), MSN, etc. Interestingly enough, that lists starts to look a lot like a list of "destination sites" - the type of site that motivates people to get an ISP in the first place. These sites also have a large enough public profile that their press releases can saturate the media. If a sufficient number of these sites (X) refuse to pay, and if a sufficient number of major ISPs (Y) choose to not implement discriminatory service, then those ISPs that do will lose, both in public opinion and in business. And likely eventually in court.
I submit that X and Y are both suprisingly small. Now, if any major ISP chooses to do the right thing, and they happen to have any major sites as their customers, the ISP now has a very good reason to throw it's peering weight around against the misbehaving ISPs. There's one market feedback loop.
But what happens if all the ISPs go bad at the same time? That's when the government should get involved, and there are many angles based on existing law, ranging from collusion/anti-trust to removing common carrier status/busting 'em for kiddie porn. Interestingly enough, this can apply at a smaller scale for those areas of the country where there is insufficient choice of ISPs.
So I think a little saber rattling is just fine, but it is too early to consider new legislation. If the market starts going the wrong way, there's plenty of existing government mechanisms to encourage it to correct itself. I can certainly sympathize with a view that's skeptical of the executive branch's inclinations to take action, but substituting legislation is not a better answer.
(*) I think that the subcategory of sites making money off high bandwidth services like VOIP that compete with offerings ISPs make is a bit different than the relatively low bandwidth offerings of a wikipedia. I don't think there is really much risk to the wikipedia's of the world. The Vonages, OTOH, are on the front lines of a battlefield.
No, it doesn't create problems, it just isn't a silver bullet to solve them. This is the extra local knowledge requirement I stated above.
Let's take the database example that many people jump to. It's certainly correct that clustered databases are complex, expensive beasts, and so if you have an application that requires a single, modifiable (not read only), ACID compliant database image for a single site, a large iron fault tolerant solution will likely make more sense than a clustered attempt.
But what if that's not your requirement? If, for example, the majority of your application's database needs are read-only, then perhaps you can split it to a set of clustered read-only databases, and an active/passive set up for your modifyable database. You then use a publishing model for changes to your read-only cluster. This pattern is applicable to a large number of online commerce sites - you have a catalog of product information that people search in. You publish updates to this catalog relatively infrequently - a few times a day or less. You have a lot smaller volume of traffic creating new commerce accounts and invoices than searching the catalog. Notice that it's okay if the updates to the catalog aren't in dead sync across all the copies of the database for a few seconds or minutes. Once you stop thinking in monolithic single database terms, it frees you to architect a more effective solution. Local knowledge.
You mention synchronized memory access. Of course it's silly to do this across a cluster. The question becomes again: do you need it? It's not uncommon for the synced piece to be a very small fraction of the overall memory requirement. So you factor the synced stuff out into procedure calls executed against a single service somewhere running on a single box, and then you let everything else exist as multiple copies in various cluster nodes for performance. Local knowledge.
Clustering is not a drop in solution; it requires careful design all the way from power supplies to application requirements. Done correctly, however, you get Google. It's about applying local knowledge to choose the most effective long-term architecture for the job.
One final OT thought: Simple is harder than complex. Maybe the exercise of trying to model your underlying requirement as a "simple web application" would be enlightening.
Fault tolerance gets you a machine that keeps running in the face of hardware failures and maintenance. The switchover time is arguably negligible.
Clustering gets you a set of services that keep running in the face of hardware failures and maintenance. The switchover time can range from negligible to huge depending on the application involved.
However, clustering also helps you to solve other problems, including scaling, software failures, software upgrades, A-B testing (running different versions side by side), major hardware upgrades, and even data center relocations.
Clustering tends to require a lot more local knowledge to get right.
So if you narrow the problem definition to hardware only, they solve the same class of problems. But when you broaden it to the full range of what clustering offers you find a greater opportunity for cost savings - because one technique is covering multiple needs.
Could you please specify where the right place is to leave feedback? Particularly for those of us that have been burned in the past and now won't buy ATI products until or unless they release specifications or open source? Since we don't have any current products, the driver feedback page is not going to work. We represent additional customers and revenue.
Cucumbers. Zucchini and all forms of Squash. Green beans...
Why do the above? It forces the spammer to house the mail instead of the recipient. If it is a spam, there's a good chance the sending site will be blacklisted before many of the recipients ever receive it.
Not perfect, but it changes the economic balance in the right direction without payment schemes.
As an '01 and before customer who opted not to use them in '02, I'm not switching back in '03 unless they overcome the switching costs for me - say by sending me a free copy of the equivalent products to those that I used in '01.
Sure, it won't win them back the revenue for '03, but that's already lost. It will get them some for '04 and beyond.
are the size implied by your description, you will not have access to the correct parts to work in this box.
A hint: Nobody, and especially no professional would do work on the infeed side of a box like that with the power still on. Sliding in a new circuit into a clean space hot, sure, but revamping a box that apparently has already had an incident, no way.
This post typed with my left hand in my back pocket.
There wasn't enough time between the start of the freefall after lunch, and the close of the markets.
Short-sellers who didn't want overnight exposure to further lies^h^h^h^h SCO press releases probably took their profits. 24% isn't bad for a day's work. Heck, anything over 5% is well worth the effort.
Nice rhetorical image. How do you know I wouldn't send a beautiful person that happened to have a loud voice?
How do you know how the PCI-SIG feels? All evidence presented shows that they have an interest in the list.
They should buy it as a gesture of apology for being rude, and because it's in their, and everyone else's best interest. In what world doesn't it make sense?
Letters from lawyers clearly have more weight than letters from organizations, which have more weight than phone calls, which have more weight than emails, which have more weight than IMs. Surely you recognize that.
This would have become a legal situation had Jim not responded to any other attempt reach him, but he was not extended that courtesy.
Had that simple action been taken, not only would the PCI-SIG not have paid for useless legal services, they would have avoided senseless damage to their goodwill.
Humorously, I just heard George W. say "There are too many lawsuits in America!" as a quote from a speech today.