I-1098 is a terrible idea. I live in WA, and I'm below the threshold so I wouldn't have to pay this tax -- yet.
The way the initiative system works in WA, the state legislature is free to make amendments after 2 years. If I-1098 passes, a simple majority vote in Olympia can change the rates & brackets.
It is going to suck even more because the tax is billed as an "excise tax" (to avoid WA state constitutional issues) so it will not be tax deductible with the IRS. 2 years from now when the brackets come down and we are all paying this tax we will be paying federal income tax on top of the excise tax unless federal and/or state law is changed.
This initiative is just going to give Olympia an excuse to avoid the difficult spending cuts that need to be made. Gov. Gregoire is leading that effort now and THAT is the right thing that must be done.
The context of the grandparent's quote is an answer to this question in the FAQ:
Even if it's legal to hire international students, won't it cost a lot of money and involve a lot of paperwork?
The document, and this question in particular, is clearly designed to be informative and tackle a specific bias that exists in the hiring process.
However, the wording is *may* not *will*, which makes it less informative, and instead of eliminating bias, it actually creates a bias in favor of hiring international students for reasons other than who is the best candidate. Who benefits from that? Candidates hired for the wrong reasons, or employers who hired employees for the wrong reasons?
The preceding statements in the answer were sufficient on their own:
No. The only cost to the employer hiring international students is the time and effort to interview and select the best candidate for the job. The international student office handles the paperwork involved in securing the work authorization for F-1 and J-1 students.
Nowhere does it advocate hiring international over U.S. students or what benefits are to using international students.
Sure, except for this unnecessary statement in the FAQ:
In fact, a company may save money by hiring international students because the majority of them are exempt from Social Security (FICA) and Medicare tax requirements.
Cheap, unimportant data is not the only factor. A more significant factor is scale. Some of the big "NoSQL" players in TFA have a very real monetary stake in the data they are putting into these systems.
No one is saying "no to SQL" because they can do without the reliability. Quite the opposite. Put a DBMS under crushing load, and availability is the first thing to go. The big players want a system that is highly available and maintains data integrity.
A typical DBMS makes strong consistency guarantees across the entire dataset. e.g. After an update is committed, all subsequent reads MUST reflect the change. Turns out this costs a lot; it is a major sacrifice to the potential throughput that could otherwise be achieved with the same hardware, and fundamentally limits the scale of the dataset. Strong consistency adds nothing to reliability and is unnecessary for many apps.
You are pretty close in your point that when you upload something to Facebook, it doesn't matter if everyone sees it instantly the next time they refresh their browser. That is absolutely true. However this is not to say that the underlying system is lacking in integrity or reliability. An "eventually consistent" data store can reliably guarantee that the data will eventually be reflected in all queries, without requiring it to be resubmitted.
This can be viewed as problem with the current browser caching paradigm. It is an important concern and I believe it can be solved with some design changes in web apps and in the browser.
Today your web browser always hits the remote server first, even if you already have a cached copy of the content. It's checking to see if its cache is still valid. If the site is down, you see an error (read: your app won't run); if the site decided to delete or change the content, your browser obliges and caches the new version, whether you wanted the old version blown away or not.
Once you start talking about full-blown web apps served up through the browser, what you really want is to connect only for software update distribution and network-oriented features that only make sense online (e.g. live chat, featured content, ads). Local-only features, e.g. word processing, should be cached in such a way that it works offline and can be rolled back if you get a bad update.
Technically one size argument is enough, but in a large enough software project the code that allocates the destination buffer is maintained separately from the code that copies into it. Any failure in communication (e.g. building against an outdated library) will lead to someone's linker writing a binary with code that will overrun a buffer.
With an explicit destination size parameter, the buffer copy code is no longer as sensitive to changes at the allocation site. A breakdown in communication will lead to a binary that produces a controlled runtime error instead of a buffer overrun.
IIRC, the "single instance storage" feature was removed from Exchange 2007. I heard a lame reason, something along the lines that it was becoming too complex to maintain the code.
OWA is pretty good, but you can't create/edit your inbox rules with OWA. If your org uses a lot of distribution lists, you're screwed without inbox rules.
Re:Noticably the fastest browser.
on
Google Chrome, Day 2
·
· Score: 4, Interesting
Not just Office -- it's the whole desktop environment. Chrome is Google's way of telling everyone that the web really is ready for primetime app development. The roadblocks of the past, like poor performance, second class UI, hacky little scripts taping everything together, etc. are not fundamental limitations imposed by the web; they were shortcomings of the legacy web browsers.
Google is trying to get good, self-respecting developers to target the web with their apps, even for traditionally "local" apps.
Look at some of the mainstays of the traditional local app platform. Chrome's approach to tabbed browsing is one step away from replacing the Windows Taskbar. Your app gets listed in the Chrome Task Manager, too. A lot like Windows Task Manager, eh? Except it's more useful. Even the hotkey to open is simpler. SHIFT+ESC instead of CTRL+SHIFT+ESC.
I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.
Yes! Here are a couple of counterpoints:
Half of your list applies to C as well, but C is still very successful. A lot of those points apply to C++ too (or used to, remember, C++ didn't even have the STL when it first came out; it was just a frontend for C!).
If I want to implement something fancy in JS, like photo editing software, most of the stuff on your list would be nice to have, but not required. Today, poor performance is a bigger barrier. This improvement broadens the scope of software that people will consider writing in JS.
I think there is a snowball effect. As the scope of software you would implement in JS increases, some of the "nice to have" features become more important, and will make it into the language.
There are also a lot of Japanese speakers among the older generation in Taiwan. There was a period of time that the schools were taught in Japanese. My grandmother-in-law grew up during that time -- she spoke mostly Taiwanese with the family, but used Japanese with her friends from school. My mother-in-law understands spoken Japanese (though she doesn't speak it).
I watched TFV in TFA too, and what he seemed to be saying was that a key to their success was having access to the source code for the operating system they were using. Oh the irony.
This is a classic example of what someone wants vs. what they are asking for.
What they don't want is this:
Someday, probably a Monday, you will get a page. The production website is timing out and they've traced it to the database. A look at the Oracle dashboard indicates that several "ad hoc" queries have been running for the past 4 hours, have blown the cache, and are churning up 99% of the read I/O on the database. You kill the queries. Some customer's ad hoc reports fail, they want to know why and they're especially irritated because they've been waiting 4 hours for the result. The other customers are upset that the main website is unavailable.
What they do want is a sandbox to play in.
The production database server is not a sandbox. It's a system of schema and queries there are all designed and QA'ed to meet an SLA. A certain amount of cache is required; a certain amount of logical I/O is possible; queries do their work within those boundaries. The tp99 is under 100ms because it was designed that way. And the schema is not even convenient for reporting. Maybe it happens to be convenient today, but that is a coincidence and things will soon change.
Everyone would be much happier if the sandbox operation could be managed separately. OTOH, improvements to the reporting schema could be made without requiring a dev+QA iteration on the production website.
Whatever you do, don't agree to support this feature without getting sign off on the additional hardware and software you need to run that sandbox. If you can't get that, get sign off on a new, weakened SLA for the main production application that will be impacted.
"Nobody studies random chaos, as there's nothing to predict."
Lots of people have studied random chaos. Laplace, Gauss, De Moivre, Chebyshev, just to name a few.
Nothing to predict? There are several amazing theorems of statistics that derive order from chaos, the central limit theorem being one of them.
The weather is a popular example of a chaotic system. That doesn't mean there is nothing to predict; I can say that there is a near 100% probability that the weather in Seattle on Feb 17, 2010 will be cloudy and between 20 and 70 degrees F. With more data, you could make stronger statements.
"but [OSS] certainly carries plenty of clear advantages over anything else."
You're right. Actually there's more to it than just allowing the general public to review the code. The important part of OSS is that it allows someone other than the manufacturer to own the software build and setup process. OSS would be worthless if it simply meant that people could see the source code, yet the manufacturer's machines still ship with everything pre-installed and ready to use. The real value comes into play when the election commission hosts the code repository and uses it to accept patches from the manufacturer, and take responsibility for building and installing all software on the voting machines.
Even if the machines are based on open source software, how do you know what has actually been deployed on the machine you use to cast your vote? Someone has to set up those machines. Any public code review or testing, no matter how thorough, is completely nullified if that isn't the software that ends up on the machine on election day.
Why do geeky people (myself included) like to wipe a new machine before they use it? Why do corporate IT departments have policies about wiping new hardware, or machines that have been infected with a virus? Simply because when you are using a general purpose computer, it is complex enough that no human can have any confidence in what it is doing unless they had control over the entire installation process.
To take it a step further, try running the code in Callgrind. Callgrind is part of the Valgrind suite. It basically runs your app on a soft CPU. It's intended for use as a profiling tool, but it gives you a complete map of what is calling what, and how many times. The output is most valuable when you create snapshots around specific use cases in the code -- you can do that with callgrind's external control tool. KCachegrind is an excellent tool for viewing callgrind output.
This is especially obvious since people already use their phones to order & buy things in places like Japan. Hopefully the patent system allows for prior art from outside the US?
IE7 isn't stable for me at all on Vista; if you are a heavy web user it is a total nightmare. If I leave behind any kind of trail of open tabs or multiple windows, before long the thing is hanging, chuffing your HTML form input (NEVER trust your input to IE7 on Vista, it's a sure way to lose data), and crashing. I have to close all my web browser windows and start over again.
Test: File copy fails after 16K files! We can't ship like this! Dev: The fix is easy and I can have it in tomorrow. PM: 16K files? Only music pirates are gonna hit this. If anyone else sees this problem it goes away with a reboot, right? Release Mgr: Won't fix!
Slashdot Mirror
I-1098 is a terrible idea. I live in WA, and I'm below the threshold so I wouldn't have to pay this tax -- yet.
The way the initiative system works in WA, the state legislature is free to make amendments after 2 years. If I-1098 passes, a simple majority vote in Olympia can change the rates & brackets.
It is going to suck even more because the tax is billed as an "excise tax" (to avoid WA state constitutional issues) so it will not be tax deductible with the IRS. 2 years from now when the brackets come down and we are all paying this tax we will be paying federal income tax on top of the excise tax unless federal and/or state law is changed.
This initiative is just going to give Olympia an excuse to avoid the difficult spending cuts that need to be made. Gov. Gregoire is leading that effort now and THAT is the right thing that must be done.
The context of the grandparent's quote is an answer to this question in the FAQ:
Even if it's legal to hire international students, won't it cost a lot of money and involve a lot of paperwork?
The document, and this question in particular, is clearly designed to be informative and tackle a specific bias that exists in the hiring process.
However, the wording is *may* not *will*, which makes it less informative, and instead of eliminating bias, it actually creates a bias in favor of hiring international students for reasons other than who is the best candidate. Who benefits from that? Candidates hired for the wrong reasons, or employers who hired employees for the wrong reasons?
The preceding statements in the answer were sufficient on their own:
Nowhere does it advocate hiring international over U.S. students or what benefits are to using international students.
Sure, except for this unnecessary statement in the FAQ:
Cheap, unimportant data is not the only factor. A more significant factor is scale. Some of the big "NoSQL" players in TFA have a very real monetary stake in the data they are putting into these systems.
No one is saying "no to SQL" because they can do without the reliability. Quite the opposite. Put a DBMS under crushing load, and availability is the first thing to go. The big players want a system that is highly available and maintains data integrity.
A typical DBMS makes strong consistency guarantees across the entire dataset. e.g. After an update is committed, all subsequent reads MUST reflect the change. Turns out this costs a lot; it is a major sacrifice to the potential throughput that could otherwise be achieved with the same hardware, and fundamentally limits the scale of the dataset. Strong consistency adds nothing to reliability and is unnecessary for many apps.
You are pretty close in your point that when you upload something to Facebook, it doesn't matter if everyone sees it instantly the next time they refresh their browser. That is absolutely true. However this is not to say that the underlying system is lacking in integrity or reliability. An "eventually consistent" data store can reliably guarantee that the data will eventually be reflected in all queries, without requiring it to be resubmitted.
This can be viewed as problem with the current browser caching paradigm. It is an important concern and I believe it can be solved with some design changes in web apps and in the browser.
Today your web browser always hits the remote server first, even if you already have a cached copy of the content. It's checking to see if its cache is still valid. If the site is down, you see an error (read: your app won't run); if the site decided to delete or change the content, your browser obliges and caches the new version, whether you wanted the old version blown away or not.
Once you start talking about full-blown web apps served up through the browser, what you really want is to connect only for software update distribution and network-oriented features that only make sense online (e.g. live chat, featured content, ads). Local-only features, e.g. word processing, should be cached in such a way that it works offline and can be rolled back if you get a bad update.
Technically one size argument is enough, but in a large enough software project the code that allocates the destination buffer is maintained separately from the code that copies into it. Any failure in communication (e.g. building against an outdated library) will lead to someone's linker writing a binary with code that will overrun a buffer.
With an explicit destination size parameter, the buffer copy code is no longer as sensitive to changes at the allocation site. A breakdown in communication will lead to a binary that produces a controlled runtime error instead of a buffer overrun.
IIRC, the "single instance storage" feature was removed from Exchange 2007. I heard a lame reason, something along the lines that it was becoming too complex to maintain the code.
OWA is pretty good, but you can't create/edit your inbox rules with OWA. If your org uses a lot of distribution lists, you're screwed without inbox rules.
Not just Office -- it's the whole desktop environment. Chrome is Google's way of telling everyone that the web really is ready for primetime app development. The roadblocks of the past, like poor performance, second class UI, hacky little scripts taping everything together, etc. are not fundamental limitations imposed by the web; they were shortcomings of the legacy web browsers.
Google is trying to get good, self-respecting developers to target the web with their apps, even for traditionally "local" apps.
Look at some of the mainstays of the traditional local app platform. Chrome's approach to tabbed browsing is one step away from replacing the Windows Taskbar. Your app gets listed in the Chrome Task Manager, too. A lot like Windows Task Manager, eh? Except it's more useful. Even the hotkey to open is simpler. SHIFT+ESC instead of CTRL+SHIFT+ESC.
If it's Perl, you never know which way the author will choose!
Maybe:
$connection->drop unless $hostname ne "slashdot.org";
Or:
$hostname ne "slashdot.org" or $connection->drop;
Or even:
my $rule = <<EoR;
if($hostname ne "slashdot.org") {
$connection->drop();
}
EoR
eval( $rule );
Isn't it grand?
Good rant!
Yes! Here are a couple of counterpoints:
I think there is a snowball effect. As the scope of software you would implement in JS increases, some of the "nice to have" features become more important, and will make it into the language.
For $1000, I could buy 7 of those "world's cheapest laptops". With the leftover money...
Laptop #1. Diet coke/mentos/laptop explosion. $2.39 from amazonfresh.com.
Laptop #2. Death by latte. $3.39 at Starbucks.
Laptop #3. Sent to the bottom of Tacoma Narrows. $4.00 bridge toll.
Laptop #4. Dowsed in sulfuric acid. Post a warning sign too! $13.76.
Laptop #5. Crushed in the depths of Lake Chelan. $39.00 Lady of the Lake fare.
Laptop #6. Left outside overnight in Seattle. FREE.
Laptop #7. "Waterproof" without any stinking $1000 spray.
There are also a lot of Japanese speakers among the older generation in Taiwan. There was a period of time that the schools were taught in Japanese. My grandmother-in-law grew up during that time -- she spoke mostly Taiwanese with the family, but used Japanese with her friends from school. My mother-in-law understands spoken Japanese (though she doesn't speak it).
I watched TFV in TFA too, and what he seemed to be saying was that a key to their success was having access to the source code for the operating system they were using. Oh the irony.
This is a classic example of what someone wants vs. what they are asking for.
What they don't want is this:
Someday, probably a Monday, you will get a page. The production website is timing out and they've traced it to the database. A look at the Oracle dashboard indicates that several "ad hoc" queries have been running for the past 4 hours, have blown the cache, and are churning up 99% of the read I/O on the database. You kill the queries. Some customer's ad hoc reports fail, they want to know why and they're especially irritated because they've been waiting 4 hours for the result. The other customers are upset that the main website is unavailable.
What they do want is a sandbox to play in.
The production database server is not a sandbox. It's a system of schema and queries there are all designed and QA'ed to meet an SLA. A certain amount of cache is required; a certain amount of logical I/O is possible; queries do their work within those boundaries. The tp99 is under 100ms because it was designed that way. And the schema is not even convenient for reporting. Maybe it happens to be convenient today, but that is a coincidence and things will soon change.
Everyone would be much happier if the sandbox operation could be managed separately. OTOH, improvements to the reporting schema could be made without requiring a dev+QA iteration on the production website.
Whatever you do, don't agree to support this feature without getting sign off on the additional hardware and software you need to run that sandbox. If you can't get that, get sign off on a new, weakened SLA for the main production application that will be impacted.
"Nobody studies random chaos, as there's nothing to predict."
Lots of people have studied random chaos. Laplace, Gauss, De Moivre, Chebyshev, just to name a few.
Nothing to predict? There are several amazing theorems of statistics that derive order from chaos, the central limit theorem being one of them.
The weather is a popular example of a chaotic system. That doesn't mean there is nothing to predict; I can say that there is a near 100% probability that the weather in Seattle on Feb 17, 2010 will be cloudy and between 20 and 70 degrees F. With more data, you could make stronger statements.
You're right. Actually there's more to it than just allowing the general public to review the code. The important part of OSS is that it allows someone other than the manufacturer to own the software build and setup process. OSS would be worthless if it simply meant that people could see the source code, yet the manufacturer's machines still ship with everything pre-installed and ready to use. The real value comes into play when the election commission hosts the code repository and uses it to accept patches from the manufacturer, and take responsibility for building and installing all software on the voting machines.
D
Even if the machines are based on open source software, how do you know what has actually been deployed on the machine you use to cast your vote? Someone has to set up those machines. Any public code review or testing, no matter how thorough, is completely nullified if that isn't the software that ends up on the machine on election day.
Why do geeky people (myself included) like to wipe a new machine before they use it? Why do corporate IT departments have policies about wiping new hardware, or machines that have been infected with a virus? Simply because when you are using a general purpose computer, it is complex enough that no human can have any confidence in what it is doing unless they had control over the entire installation process.
D
To take it a step further, try running the code in Callgrind. Callgrind is part of the Valgrind suite. It basically runs your app on a soft CPU. It's intended for use as a profiling tool, but it gives you a complete map of what is calling what, and how many times. The output is most valuable when you create snapshots around specific use cases in the code -- you can do that with callgrind's external control tool. KCachegrind is an excellent tool for viewing callgrind output.
No, grandparent post only said China is not run by laws; this does not mean anarchy. China relies heavily on guanxi.
This is especially obvious since people already use their phones to order & buy things in places like Japan. Hopefully the patent system allows for prior art from outside the US?
This is not the first time they've found soft dinosaur tissue in the Dakotas. Maybe the submitter was confusing this with an earlier soft tissue find in South Dakota.
IE7 isn't stable for me at all on Vista; if you are a heavy web user it is a total nightmare. If I leave behind any kind of trail of open tabs or multiple windows, before long the thing is hanging, chuffing your HTML form input (NEVER trust your input to IE7 on Vista, it's a sure way to lose data), and crashing. I have to close all my web browser windows and start over again.
Yes there is, and it's called advertising. You get people's attention, on the chance that people are more likely to pay for things they are aware of.
D
I can just imagine the warteam conversation:
Test: File copy fails after 16K files! We can't ship like this!
Dev: The fix is easy and I can have it in tomorrow.
PM: 16K files? Only music pirates are gonna hit this. If anyone else sees this problem it goes away with a reboot, right?
Release Mgr: Won't fix!