1) fix the PAGEFILE. Go inot the settings and change ti to fixed size - 2x-3x size of ram - both of minimum and maximum size. Do not let WInodws manage it! [ ... ]

Better still, move PAGEFILE.SYS off of C: entirely, preferably on to its own spindle if you can. That way the swapper isn't having a fight with every other application in the system for accessing system files; and PAGEFILE.SYS itself won't become fragmented.

Consider moving %TEMP% and %TMP% off of C: as well.

4) Dump the System Restore from time to time. This is just junk removal. [ ... ]

Sadly, this appears to be an all-or-nothing affair -- on XP, you can either delete all restore points or none of them. It would be nice to delete those that are, say, more than a year old.

Some years ago after being laid off from one programming job, my old CS prof from college suggested I stop by to interview with the Epic recruiter who was visiting the campus. I was told to block out about four hours time, and that it would be a very in-depth technical interview. It turned out to be nothing of the sort: it was maybe ten minutes of talk with a human being, and hours and hours of filling out a badly-written "technical exam". Allegedly it involved seeing how well the taker could think about programming languages and programming language concepts by giving us a toy language to write a parser and compiler for, but ... holy toledo, was it a stinker.

First, the language was defined in plain English. There was no BNF. When ambiguities of English occurred (as they always do), the Epic rep was unable to give any resolution as to what the language was supposed to do. My protest of, "Well, if you don't know what it's supposed to do, how can you expect me to write a parser or compiler for it?" fell on deaf ears.

Second, certain mathematical operations were supposed to be supported ... but the language was vague: they were supposed to have their "conventional" meanings. But some mathematical operators are defined sort of vaguely: for instance, it's not really well-defined mathematically what the modulo of two negative numbers are. As a result, different programming languages tend to implement it differently. (For instance, C++03 says it's implementation-dependent, while C++11 has a strict policy on it.) How did they want the modulus operator implemented? They had no idea.

Ultimately, when it came to writing a parser and compiler for their toy language I decided to do it the right way as opposed to their way. Instead of having an ad-hoc thing, I turned the exam over and started writing a formal BNF and lex/yacc rules on the back of the pages. I took the full four hours to do the technical exam, turned it in, told them that my work was on the *back* of the exam and not the front, and walked out.

Six weeks later, not having heard a thing from Epic, I sent them a politely-worded email saying, "If I'm going to spend four hours on a Saturday on an interview for Epic, I would appreciate the courtesy of being told whether I would be receiving a job offer or not."

A week after that I received a one-line email: "We regret to say that we're going with other candidates."

Anyway. That's my experience with Epic. Take it for whatever it's worth. I didn't think much of their interview process, and they sure didn't think much of me.

...federal officials forced American tech companies to participate in the NSA's controversial PRISM program.

You misspelled "illegal." HTH. HAND.

In a filesystem like EXT3, if you open a file, seek to some offset, and write new data, EXT3 will write the new data to the existing disk block in place. ZFS, however, will allocate a new block for that offset (copy on write), write the modified data to it, and update the block chain. The result is that it's apparently very easy to badly fragment a ZFS file (do a Google search for "ZFS fragmentation" to see various stories and tests people have written).

You can apparently mitigate the problem by occasionally copying the entire affected file -- Oracle's own whitepaper on the subject apparently reads, "Periodically copying data files reorganizes the file location on disk and gives better full scan response time."

Bottom line: ZFS is not a panacea, nor is it simple. There are myriad options, and trade-offs to all of them.

HTML5 is, indeed, a programming language -- at least when paired with CSS3. You can implement Rule 110 in nothing but HTML5 + CSS3, and Rule 110 is known to be Turing-complete. Ergo, HTML5 + CSS3 is capable of any computable process, and is a full programming language.

It's a horrible programming language, but hey, when has that gotten in the way of widespread acceptance?

Why is that link relevant? Because they were all made using Kdenlive.

When I first started mucking around with digital video, I tried a bunch of free/libre packages, and formed the following opinions of each:

Windows Movie Maker
Yes, $(GOD) help me, I gave it a serious try. To my utter surprise, it mostly worked and did what I wanted without crashing. However, the UI was rather inflexible, and I needed more than the handful of features it offered, so I kept looking.

Cinelerra
Every Google search for free video editing software always turns this up, so I tried it. Then, ten minutes later, I had to stop trying it because it kept crashing and/or hanging at the slightest provocation. It has an impressive-looking array of features, and the editing timeline looks quite powerful. Evidently, you can do some fairly impressive things with Cinelerra, provided you can identify and avoid all its weak spots.

Pitivi
The last time I tried this, it was unreliable, under-featured, and incredibly slow. Just loading a one hour-long video clip into the timeline took several minutes as it tried to generate thumbnails and an audio waveform for the clip.

OpenShot
Assuming I'm remembering this package correctly, all it does is assemble edits -- that is, you can tack together a bunch of clips one after the other to create a larger work. If you want to do any effects or titling, you're SOL. Perhaps the Kickstarter-funded upgrade will yield some improvements.

Lightworks
I had to learn something the hard way with this package: This is a professional package. By that, I don't mean it has a ton of features (although it certainly does). I mean it expects a certain level of media asset before it will operate on it in the manner you expect. Us mere proles are satisfied to use MP4 or MKV or ($(GOD) help us) AVI files. However, in the pro space, you have files that contain not just compressed audio and video, but also timecode. And not just timecode measured relative to when you last pressed the RECORD button, but also a master timecode from an achingly accurate central timecode generator fed to all your cameras and microphones. This not only means all your cameras and mics are in precise sync ('cause otherwise their internal clocks will drift relative to each other), but you can trivially sync all your master footage and then intercut shots without even thinking about it. Also, near as I can tell, there's no such thing as inter-frame compression in professional video. Each frame is atomic, which means you can cleanly cut anywhere, but it doesn't compress anywhere near as small as, say, H.264.

The result is that, if you don't have equipment that generates all this metadata for you, then you need to convert it from the puny consumer format you're likely using. This means having truly monstrous amounts of disk available just to store the working set, and tons of RAM to make it all work. And hopefully your conversion script(s) didn't cough up bogus timecode.

So, yes, Lightworks is very very nice, if you have the proper resources to feed it. I don't, so I've set it aside for that glorious day when I get some proper equipment :-).

Kdenlive
Kdenlive is built on top of the MLT framework, and is about the best and most reliable thing I've found out there that doesn't cost actual money (either directly or indirectly). It has a non-linear timeline editor, it supports a wide variety of media formats, and it has a modest collection of audio and video effects (almost none of which you will use).

One of the more amazing things Kdenlive does is transparently convert sample and frame rates. Without thinking about it, my first video involved using a 44KHz WAV file, a 48KHz WAV file, and a 44KHz MP3 file, with the output audio to be 48KHz AAC. I feared I was going to have to convert all the sources to the same format, but Kdenlive quietly resampled them all when compiling the output video file, and everything came out undistorted and in sync.

Kdenlive does occasionally crash, which is annoying, but it has never destroyed my work. It has a fairly robust crash recovery mechanism, and you may lose your most recent one or two tweaks to the timelines, but you won't lose hours of work.

Kdenlive is not perfect, of course. It has limitations and annoyances that occasionally make me search for another video editor. But if, as I was, you're new to video editing, it will take you a while to find those limitations. Kdenlive has certainly served me very well in the meantime, and I think it's the most reliable, most capable, and most easily accessible Open Source video editor out there.

At OSCON 2006 I was sitting in one of the green rooms (the spaces set aside for speakers before presentations). My laptop was open and I was happily hacking away on a project. As I killed a bug and checked the code back in, I muttered under my breath, "Python, I love you. You make the hard stuff so easy."

I noticed a few seconds later the room had gone utterly silent. I looked up, and sitting at the table across from me was Damian Conway, tapping away on his own laptop doing his own thing. I blinked a couple of times and suddenly noticed the entire room was expecting a Perl-vs-Python argument to erupt.

Damian looked up from his work, noticed everyone was looking nervous. He looked over at me, I gave a "I don't know what's up with them, uh, help?" look and a shrug.

Damian then looked back at the crowd and grinned. "Listen, the only thing I love more than Perl is well-written software, even if it's written in Python." He looked back over to me. "Kill a bug, didja?" I nodded. He gave me a smile and a thumbs-up, then returned to his code. I returned to mine, and after a few seconds the room let out his breath.

I love Python. But the only thing I love more than Python is well-written software, even if it's written in Perl. :)

...I'm going to trust a link to install software on Android from outside of the Play store?

I think not.

Clearly you've never heard of the F-Droid project. Go read up on it.

This is a non-story. It has always been a non-story. It has already been investigated, and what turned up was a gigantic pile of nothing. But then, that's all Daryl Issa's "investigations" have ever turned up.

Yes, the IRS investigated a bunch of applications for tax-exempt status for a number of "Tea Party" groups. They also performed the same investigations on so-called liberal groups. They're supposed to do that; otherwise any moron could claim tax-exempt status. Were there problems with the investigations? Yes, because the tax law that requires them is so vague that it's basically left entirely to the discretion of the investigator.

Were any applications denied? No, not really. Did the IRS investigate more "Tea Party" groups than liberal groups? It would appear so. It would also appear that there were a hell of a lot more "Tea Party" applications flooding in during the timeframe in question (which makes sense, given that the "Tea Party" is not grassroots, but entirely the construction of FreedomWorks).

As for how "terribly convenient" it is for multiple IRS personnel under investigation to have lost the data in question, well... Considering that the IRS is underfunded (sounds weird, but it's true); and considering that they have tens of thousands of personal computers, none of them brand new, and all of them in various states of disrepair and subjected to various forms of abuse; and considering that every one of those tens of thousands of computers are running FUCKING WINDOWS , then you are provably a drooling idiot if you think the probability for unrecoverable data loss is anything less than 1.0.

The only story here is that IRS regs concerning tax-exempt political advocacy organizations are hopelessly vague. Moreover, it's not a story that belongs on a tech-oriented site. If I wanted to read about fabricated right-wing ghost stories, I'd visit RedState. Get this shit off Slashdot.

written by richard lightman [ ... ] his web site is now offline: you can get a copy of depinit however using archive.org.

Last snapshot I could find on archive.org: http://web.archive.org/web/200...

here on Slashdot we frequently have people (the "2nd amendments folks") allude to using their guns to overthrow the US government by force (which is obviously a totalitarian strategy) and also threatening to arbitrarily kill people for various perceived offences without a proper trial

Hi! As a card-carrying NRA member, I'm one of those "Second Amendment folks" you're talking about here. A couple of points:

1. It's "the Second Amendment," not "the Second Amendments." There's only one Second Amendment.

2. Overthrowing the government by force is the right of the people, yes. It's also unbelievably stupid in the overwhelming majority of cases. Civil war is horrific and something best avoided. The Framers did intend the armed populace to be a bulwark against governmental infringements on liberty, yes, but mostly by means of making the government afraid to violently oppress the people for fear of the armed resistance they would face.

   In this, the Framers have been overwhelmingly successful: where in past eras a government would've just bludgeoned people into believing the law was what they said it was, nowadays our politicians have learned to couch things in terms of "counterterrorism" and "protecting the children" and we'll quite amicably assent to whatever they say the law is.

   The Framers had the right idea, they just weren't quite clever enough: they thought the risk would be a government that used force against the people, whereas the real risk is from public relations and focus groups.

   Anyway -- short version: although I am one of those "Second Amendment folks," I, and all of the other "Second Amendment folks" I know, am absolutely against civil war. Horrible, terrible idea. I've seen enough gunshot wounds already in my life, thank you very much: I feel no need to be the cause of them.

3. This would amount to "terroristic threats", and would be considered grossly illegal in all 50 states. I, and all of the other "Second Amendment folks" I know, think this behavior is reprehensible.

I'm not weighing in on that one. I'm only correcting the original poster, who said the U.S. rarely waives sovereign immunity. In fact, the opposite is true: it rarely invokes it. Tens of thousands of tort claims against the U.S. government are underway even as we speak, all of them with waived sovereign immunity.