The boot information for your OS has to live somewhere. If you want it to be any smarter than "load the first thing it finds", starting in the MBR and going from there is smart. Easy to do in the constraints of an early boot environment.
And either way, applications should not be mucking with the low-level bits of your hard drive without extensive documentation of that fact at least.
There's a long history of boot loaders living there: Systems that treat "slice 2" as the whole disk typically use it for just that: Storing boot information outside the other partitions.
And, ultimately, OS components are allowed to touch that and applications in general should not.
Except it's a non-linear load, so you need some bulkier components to filter out the harmonics. It's not phase-shift that makes the power factor what it is.
I'd like to see metrics about the edits displayed
on
When Wikipedia Fails
·
· Score: 1
I'd love to see a count of edits, time of the most recent, scope of the changes quantified -- I'd love to have a glance at how stable a page is, too, to garner trust in its information.
With test-first development, one can even work in tests with the design docs.
class TestMyUnit Test::Unit::TestCase
def test_feature_foo_with_bar
a = Foo.new
b = Bar.new
assert(a.frob(bar))
assert(File.read('designdocs').grep('Foo connects to Bar'))
end end
That, along with some statements of purpose for each bit and a commitment to keeping things simple should suffice. Each feature should be mentioned in the design docs, at least. The rest is just work policy on keeping it up to date.
Slashdot Mirror
I'm not just self-taught about computers, but entirely self-taught.
I put this in bold print on my resume. I bragged that I learn fast and learn well.
And I backed it up at the interview.
No, that's for people who are bad at geography.
Yes, so if more people do that, that will not be an acceptable tactic from the government at all.
... That's bigamy.
Or run things that handle their errors and check your work.
The boot information for your OS has to live somewhere. If you want it to be any smarter than "load the first thing it finds", starting in the MBR and going from there is smart. Easy to do in the constraints of an early boot environment.
And either way, applications should not be mucking with the low-level bits of your hard drive without extensive documentation of that fact at least.
There's a long history of boot loaders living there: Systems that treat "slice 2" as the whole disk typically use it for just that: Storing boot information outside the other partitions.
And, ultimately, OS components are allowed to touch that and applications in general should not.
The problem is, we teach Palmer Script, which is an ergonomic and legibility anti-pattern if there ever was one.
If we taught a roughly connected italic, we'd all write in a legible script.
Early nurture wins!
Caught that myself yesterday. http://aria.blogs.theinternetco.net/2010/02/11/kb977165-causes-a-blue-screen/
I, for one, welcome our new ractor overlords.
I was unschooled past 4th grade.
I own a small ISP and computer repair shop.
I was working at 13, doing tech support for the company I now own.
I spent time in the theater. I explored Canada. I biked the west coast of the USA.
All in all, it was a rocking way to live. It still is.
I learned calculus last year. Finally had a use for it. Made perfect sense, since I had a reason to.
Learned trigonometry engineering the house my parents built. Dad learned with me, since he'd forgotten what he learned in school.
Except it's a non-linear load, so you need some bulkier components to filter out the harmonics. It's not phase-shift that makes the power factor what it is.
So very hear you on the Linksys.
Power control is expensive. It's usually skimped on.
The same components with a high-quality regulated power supply would be pretty much failproof.
Actually, they're computer security researchers.
Think "Masters of Computer Security" as a degree. Yes, UC Davis has a program for this.
Under Linux and using some hardware controllers, RAID arrays can be reshaped when drives are all a larger size, and to add new drives.
Also, sub-optimal, but possible is to use, say, 2 250gb partitions on a 500gb drive, and expand that way.
Strange but works, if your RAID driver is flexible enough.
This is why innocence is presumed.
I'd love to see a count of edits, time of the most recent, scope of the changes quantified -- I'd love to have a glance at how stable a page is, too, to garner trust in its information.
Any time, Zedas!
Um, Duh.
Ditto! I would love to have a card with drivers that don't suck, and are usable on something other than the most vanilla distro and CPU.
I have a radeon 9200 as well because of this. It works, at least.
With test-first development, one can even work in tests with the design docs.
class TestMyUnit Test::Unit::TestCase
def test_feature_foo_with_bar
a = Foo.new
b = Bar.new
assert(a.frob(bar))
assert(File.read('designdocs').grep('Foo connects to Bar'))
end
end
That, along with some statements of purpose for each bit and a commitment to keeping things simple should suffice. Each feature should be mentioned in the design docs, at least. The rest is just work policy on keeping it up to date.
Let them.
I'll keep using postgresql and smirking.
It's its, not it's, unless you meant it is, then it is, otherwise it's its that's its.
Its.