Pull the drive, make an image of it, then repeatedly rap it sharply (and flat) on the desk until it makes clicky-crunchy noises and stops working. Around 5000 Gs several times should do the trick.
Then reinstall it in the laptop.
Return laptop for service of failed HDD and other issue.
Modeling doesn't actually model everything, and an unknown factor can easily arise. It's easy to design a product, but hard to actually design one that works the first time around flawlessly.
...just set up caching and some dedicated links to keep the traffic off of the "main backbone" links. That just sounds like someone actually hired a halfway decent network engineer.
If you want to distribute a lot of high-bandwidth content, then you need a lot of bandwidth.
Medium at the most! Any decent steak should be pink, and a good one red in the middle. Otherwise, we might as well just eat a chunk of brisket.
Some cuts need to be cooked to hell and back to be edible, but good rib steaks, filets, strips, and T-bone's aren't among them.
And think of your weight. Over-cooked beef is easier to digest, and having more calories end up in the commode instead of one's personal fat stores is not entirely a bad thing for many of us.
Now, pork, chicken, and a multitude of other meats need to be cooked completely to avoid parasites and disease. But not beef.
If you actually know what you are doing, Access is actually a pretty good development platform. It really is what VB should have been all along. Doing it correctly isn't for the faint of heart nor the inexperienced "guy who knows computers in the department" developer though. It's a LOT of work.
The biggest issue is that MS markets it as a database app, not a dev platform.
But there are some caveats to its use.
1. Never bind controls that can be edited to any datasource. Sorry, but you really need to write code to fill them in, check them, then write them to the back end.
2. Never store any data in an MDB file. Always use a real backend server such as MSSQL, Oracle, or even Postgres or MySQL.
3. Once it works, create an MDE file and only run MDEs on clients, never the "source" MDB.
4. You are checking your db schema revision and comparing it to allowed client app revisions, right?
Still, there are newer platforms available, and quite often a web-based app will be easier to build and maintain.
It sounds like she resorted to using the argument of "don't confuse me with facts that conflict with my emotions."
Sadly, we can't just make these important decisions on emotion or on potentially flawed data. There is a cost associated with them, and a potentially heavy one at that.
There is a point where regulations can become onerous enough to stop manufacturing activity from taking place, and if that happens, then a lot of jobs disappear, and a lot of goods are not produced.
It is necessary to think these things through properly, and decide not only that we want to do something, but how, and on what timelines.
Simply mandating reductions in fuel use with no viable alternatives being available is national suicide.
And does anyone actually believe that China and India are actually going to comply with clean air agreements?
The rights enumerated in the Bill of Rights are not an exhaustive list of all rights. The courts can and do find additional ones from time to time, and that is legitimate.
If the disc is scratched on the "top" surface, you may be SOL. The very thin top surface allows even small scratches to physically remove the reflective aluminum layer that actually stores the data. Top scratches are irreperable.
Scratches on the bottom surface can be carefully polished out, and generally won't affect the actual data stored on the disc. They just refract the laser in unpredictable directions that keep it from detecting the "bits" etched on the aluminum layer.
I have a Cricket phone with a $50/mo plan that is completely unmetered for voice, web, and text. The only add-on is roaming out of the relatively limited service area, which I don't do very often at all.
...just RTFB and save myself 10's of thousands of dollars and a year or three of time? (In theory - assuming that I didn't care about the degree, just the knowledge itself?)
Is actually pretty pricey. Pricey enough that for prototyping more than a few parts it would be cheaper and easier to just buy a small CNC mill and lathe. Then you can make pieces parts to your heart's content really cheaply.
Ebay some used gear, or roll your own from the cheap manual mills and lathes out on the market. It's not trivial, but not as difficult as building, say, a decent real database app either.
Even the absolute best, most elite, and well-equipped soldiers can become cannon fodder when they are ordered to march into an artillery barrage. This applies to artillery crews manning huge guns too.
I've met quite a few excellent teachers, and some brilliant students. Even some of the most "disadvantaged" kids can be brilliant learners - if they want to.
In most of the USA, education is of really good quality and quantity, but we still have pockets where it is a social stigma to actually learn. Peer pressure stupididty, if you will.
From my personal experience, you are right on point with combining math and science. I personally learned a lot more math in my physics class than I ever did in the official "math class".
Math that is disconnected from any link to the "real world" or "practical application" is just a pointless exercise in flipping symbols around.
Math isn't a "thing" it is a language used to express the relationships between quantities. Just like any language, learning the "words and rules" isn't enough, it needs to be linked to some sort of actual meaning.
And for the love of God, stop ever grading on homework and "effort". All that should ever count is how much the kid learned in a semester. If they learned extremely well, give them an A. If they are still clueless, a F is appropriate.
If you want to really motivate students, tie their future "social benefits" to a diploma. No diploma, no benefits. None. Zero. Until they earn a diploma, that is.
The example of the widget's patentability ignores that not all configurations are "novel" and "non-obvoious".
I like the standard that the Supreme Court put forth in the KSR case. In a nutshell, simply combining already known components and design elements and getting the expected result is not patentable. If, however, the result is not something anyone "skilled in the art" would expect, then it qualifies.
So, say we design a chemical plant to produce gasoline from coal (which has been done many times before), but happen to run across a tweak to the materials in the pipes that causes the reactions to occur faster than theory predicts, we have a patentable configuration. The addition of a previously unknown catalyst is the patentable idea, not the already-known process.
Unless the code to be patented does something unexpectedly beneficial, it falls into the same category of "obvious". Just solving a new question with a combination of already-known steps doesn't cut it here.
There's so MUCH advertising on the web that we're basically running out of pages and places to put it. Everyone's chasing the same advertising dollars, and there IS a point where the advertisers are tapped out.
Nobody pays attention to sustained revenues, rather they are chasing exponential growth that eventually flattens out as businesses mature.
A lot of web apps don't use those anyway, and just tend to store one row in a table. And if the data becomes unreadable, nobody cares since it's not really important data in the first place.
For business critical apps, that should scare the bejezzus out of the owner and coders.
I agree on most of the advice you give, especially in light of the major performance gains that can be realized by writing smarter queries and properly indexing the fields used often in WHERE clauses. With well-written code, properly indexed tables, and good queries, the cache can be unnecessary.
That said, the cache is still quite helpful if you do a lot of traffic that tends to hit the same datasets repeatedly. Blogs, news sites, and "informational" websites come to mind.
For environments that are "write heavy" compared to reads, the cache is of limited utility or even counterproductive, and watching the queries, table structure, and code like a hawk are required.
In some cases the only way out is setting up a real db cluster. But that should be a last resort, as just throwing hardware at a pig of an app is a waste of money compared to optimizing the database, queries, and code.
The most frustrating situation is when we're stuck with "legacy" setups running some off-the-shelf app and have little control over the access patterns and structure, and no ability to change the app. In those cases, a cache really can help.
I guess that's where the full-blown version will be useful.
All the possible tradeoffs can make your head explode.
Slashdot Mirror
Pull the drive, make an image of it, then repeatedly rap it sharply (and flat) on the desk until it makes clicky-crunchy noises and stops working. Around 5000 Gs several times should do the trick.
Then reinstall it in the laptop.
Return laptop for service of failed HDD and other issue.
How the hell is Reiser posting from prison?
Modeling doesn't actually model everything, and an unknown factor can easily arise. It's easy to design a product, but hard to actually design one that works the first time around flawlessly.
Craftsmen are still needed in meat-space.
...just set up caching and some dedicated links to keep the traffic off of the "main backbone" links. That just sounds like someone actually hired a halfway decent network engineer.
If you want to distribute a lot of high-bandwidth content, then you need a lot of bandwidth.
Yawn.
Even if possible, I don't upgrade boxes that I can't get physical access to, or at least hit via an IP KVM so that reinstallation via CD is possible.
But I'm just really conservative on that.
Ugh.
Medium at the most! Any decent steak should be pink, and a good one red in the middle. Otherwise, we might as well just eat a chunk of brisket.
Some cuts need to be cooked to hell and back to be edible, but good rib steaks, filets, strips, and T-bone's aren't among them.
And think of your weight. Over-cooked beef is easier to digest, and having more calories end up in the commode instead of one's personal fat stores is not entirely a bad thing for many of us.
Now, pork, chicken, and a multitude of other meats need to be cooked completely to avoid parasites and disease. But not beef.
Steak tar-tar anyone? With a raw egg on top?
Okay, the last one is a little bit of a stretch.
But sushi is good stuff!
but...
If you actually know what you are doing, Access is actually a pretty good development platform. It really is what VB should have been all along. Doing it correctly isn't for the faint of heart nor the inexperienced "guy who knows computers in the department" developer though. It's a LOT of work.
The biggest issue is that MS markets it as a database app, not a dev platform.
But there are some caveats to its use.
1. Never bind controls that can be edited to any datasource. Sorry, but you really need to write code to fill them in, check them, then write them to the back end.
2. Never store any data in an MDB file. Always use a real backend server such as MSSQL, Oracle, or even Postgres or MySQL.
3. Once it works, create an MDE file and only run MDEs on clients, never the "source" MDB.
4. You are checking your db schema revision and comparing it to allowed client app revisions, right?
Still, there are newer platforms available, and quite often a web-based app will be easier to build and maintain.
It sounds like she resorted to using the argument of "don't confuse me with facts that conflict with my emotions."
Sadly, we can't just make these important decisions on emotion or on potentially flawed data. There is a cost associated with them, and a potentially heavy one at that.
There is a point where regulations can become onerous enough to stop manufacturing activity from taking place, and if that happens, then a lot of jobs disappear, and a lot of goods are not produced.
It is necessary to think these things through properly, and decide not only that we want to do something, but how, and on what timelines.
Simply mandating reductions in fuel use with no viable alternatives being available is national suicide.
And does anyone actually believe that China and India are actually going to comply with clean air agreements?
The rights enumerated in the Bill of Rights are not an exhaustive list of all rights. The courts can and do find additional ones from time to time, and that is legitimate.
If the disc is scratched on the "top" surface, you may be SOL. The very thin top surface allows even small scratches to physically remove the reflective aluminum layer that actually stores the data. Top scratches are irreperable.
Scratches on the bottom surface can be carefully polished out, and generally won't affect the actual data stored on the disc. They just refract the laser in unpredictable directions that keep it from detecting the "bits" etched on the aluminum layer.
...to PJ at Groklaw. The summary is a straight copy-and-paste of her coverage of this issue that was posted days ago.
The solution is obvious and easy: no budget in place, no payments at all.
Problem solved.
I have a Cricket phone with a $50/mo plan that is completely unmetered for voice, web, and text. The only add-on is roaming out of the relatively limited service area, which I don't do very often at all.
...just RTFB and save myself 10's of thousands of dollars and a year or three of time? (In theory - assuming that I didn't care about the degree, just the knowledge itself?)
The P2P apps will be updated to use exclusively SSL-encrypted connections through an onion routing algorithm.
Great. Just what we need.
Is actually pretty pricey. Pricey enough that for prototyping more than a few parts it would be cheaper and easier to just buy a small CNC mill and lathe. Then you can make pieces parts to your heart's content really cheaply.
Ebay some used gear, or roll your own from the cheap manual mills and lathes out on the market. It's not trivial, but not as difficult as building, say, a decent real database app either.
on the battle.
Even the absolute best, most elite, and well-equipped soldiers can become cannon fodder when they are ordered to march into an artillery barrage. This applies to artillery crews manning huge guns too.
I've met quite a few excellent teachers, and some brilliant students. Even some of the most "disadvantaged" kids can be brilliant learners - if they want to.
In most of the USA, education is of really good quality and quantity, but we still have pockets where it is a social stigma to actually learn. Peer pressure stupididty, if you will.
From my personal experience, you are right on point with combining math and science. I personally learned a lot more math in my physics class than I ever did in the official "math class".
Math that is disconnected from any link to the "real world" or "practical application" is just a pointless exercise in flipping symbols around.
Math isn't a "thing" it is a language used to express the relationships between quantities. Just like any language, learning the "words and rules" isn't enough, it needs to be linked to some sort of actual meaning.
And for the love of God, stop ever grading on homework and "effort". All that should ever count is how much the kid learned in a semester. If they learned extremely well, give them an A. If they are still clueless, a F is appropriate.
If you want to really motivate students, tie their future "social benefits" to a diploma. No diploma, no benefits. None. Zero. Until they earn a diploma, that is.
The example of the widget's patentability ignores that not all configurations are "novel" and "non-obvoious".
I like the standard that the Supreme Court put forth in the KSR case. In a nutshell, simply combining already known components and design elements and getting the expected result is not patentable. If, however, the result is not something anyone "skilled in the art" would expect, then it qualifies.
So, say we design a chemical plant to produce gasoline from coal (which has been done many times before), but happen to run across a tweak to the materials in the pipes that causes the reactions to occur faster than theory predicts, we have a patentable configuration. The addition of a previously unknown catalyst is the patentable idea, not the already-known process.
Unless the code to be patented does something unexpectedly beneficial, it falls into the same category of "obvious". Just solving a new question with a combination of already-known steps doesn't cut it here.
joysticks have been analog since, what, the 1980's?
There's so MUCH advertising on the web that we're basically running out of pages and places to put it. Everyone's chasing the same advertising dollars, and there IS a point where the advertisers are tapped out.
Nobody pays attention to sustained revenues, rather they are chasing exponential growth that eventually flattens out as businesses mature.
A lot of web apps don't use those anyway, and just tend to store one row in a table. And if the data becomes unreadable, nobody cares since it's not really important data in the first place.
For business critical apps, that should scare the bejezzus out of the owner and coders.
Yep - it sounds like the Assembly Language version of a DB, built for massive speed but requiring very careful programming to avoid crashes.
Sometimes that's just what you need. Sometimes it's exactly the worst possible approach.
I say let the problem requirements decide which to use.
I agree on most of the advice you give, especially in light of the major performance gains that can be realized by writing smarter queries and properly indexing the fields used often in WHERE clauses. With well-written code, properly indexed tables, and good queries, the cache can be unnecessary.
That said, the cache is still quite helpful if you do a lot of traffic that tends to hit the same datasets repeatedly. Blogs, news sites, and "informational" websites come to mind.
For environments that are "write heavy" compared to reads, the cache is of limited utility or even counterproductive, and watching the queries, table structure, and code like a hawk are required.
In some cases the only way out is setting up a real db cluster. But that should be a last resort, as just throwing hardware at a pig of an app is a waste of money compared to optimizing the database, queries, and code.
The most frustrating situation is when we're stuck with "legacy" setups running some off-the-shelf app and have little control over the access patterns and structure, and no ability to change the app. In those cases, a cache really can help.
I guess that's where the full-blown version will be useful.
All the possible tradeoffs can make your head explode.