It was never widely known that Sega of Japan was, for a time, negotiating to merge with/acquire The 3DO Company. Unfortunately, best available information suggests that Trip Hawkins, 3DO's chairman and CEO, wanted too much, and the deal fell through.
That's a nice concept as far as it goes, but at some point you're still dependent on hardware-specific drivers from Lenovo. As of this writing, you can pick up device drivers piecemeal. But once they get it into their tiny little brains to create a single "Universal Installer" that bundles all the necessary drivers with all the unnecessary, unwanted bloatware and spyware, you're back in the same leaky boat.
Frankly, I'm having a hard time seeing how Lenovo recovers from this.
Expand systemd to the point where large swaths of everything depend on it, so that he is controlling as much of the code base as possible.
Insult Linus Torvalds for a while to try to undermine his authority.
Fork Linux, or demand that Linus give control of Linux over to him, or he will rage-quit and take his code with him.
I don't see it unfolding that way. Remember what happened when BitKeeper tried to get up in his business. Linus, if provoked, could write an init/system management framework in a couple weeks (and probably name it "twerp" or some such). And I suspect he would do so long before things got to stage #3, just to prove the point.
He's implying that developers will specify a complete environment where every DLL available to the application within the environment is exactly what the developer used. There is no DLL hell because you run what the developer ran, and it doesn't matter if you have seventeen different incompatible versions of (to pick windows example everyone's familiar with) mfc42.dll, because things inside the container won't know that you have those dlls.
In that case, why bother with dynamic linking at all? Why not statically link everything? The effect is essentially the same -- you get exactly what the developer had. You also get no shared code pages -- even if you're using exactly the same library as someone else -- and bloated memory and disk usage since you have your own private copy of everything. Disk may be "cheap," but it's still surprisingly easy to fill up a 16GB eMMC device.
Am I getting hopelessly old and unable to appreciate new things, or is this not anywhere near as whoop-de-doo as they're making out?
"You can update transactionally!!" Great. What does that mean? Is it like git add newapp; git commit -a? If so, how do I back out a program I installed three installations ago?
Transactional updates have lots of useful properties: if they are done well, you can know EXACTLY what's running on a particular system, [... ]
dpkg -l
You can roll updates back, [... ]
dpkg -i <previous_version>
...lets you choose exactly the capabilities you want for yourself, rather than having someone else force you to use a particular tool.
#include <cheap_shots/systemd.h>
Because there is a single repository of frameworks and packages, and each of them has a digital fingerprint that cannot be faked, two people on opposite ends of the world can compare their systems and know that they are running exactly the same versions of the system and apps.
debsums
Developers of snappy apps get much more freedom to bundle the exact versions of libraries that they want to use with their apps.
...Did this guy just say he brought DLL Hell to Linux? Help me to understand how he didn't just say that.
I bet the average system on the cloud ends up with about three packages installed, total! Try this sort of output:
$ snappy info
release: ubuntu-core/devel
frameworks: docker, panamax
apps: owncloud
That's much easier to manage and reason about at scale.
No, it isn't!! What the hell is OwnCloud pulling in? What's it using as an HTTP server? As an SSL/TLS stack? Is it the one with the Heartbleed bug, the POODLE bug, or some new bug kluged in by the app vendor to add some pet feature that was rejected from upstream because it was plainly stupid?
Honestly, I'm really not getting this. It just sounds like they created a pile of tools that lets "cloud" administrators be supremely lazy. What am I missing here?
I worked for NTG/3DO for just under five years, so I know (knew) the machine inside and out. It will be interesting to go through this code and see what kind of tradeoffs were made.
Some comments on the README:
My friends at 3DO were begging for DOOM to be on their platform and with christmas 1995 coming soon (I took this job in August of 1995, with a mid October golden master date), I literally lived in my office, only taking breaks to take a nap and got this port completed.
*snerk* I could have told you at the time that a ten-week dev cycle was crazy talk.
Shortcuts made...
3DO's operating system was designed around running an app and purging, there was numerous bugs caused by memory leaks. So when I wanted to load the Logicware and id software logos on startup, the 3DO leaked the memory so to solve that, I created two apps, one to draw the 3do logo and the other to show the logicware logo. After they executed, they were purged from memory and the main game could run without loss of memory.
An interesting and valid approach (3DO's OS had full memory tracking). I'd be interested to know which of the 3DO libs was leaking memory on you.
The verticle walls were drawn with strips using the cell engine. However, the cell engine can't handle 3D perspective so the floors and ceilings were drawn with software rendering. I simply ran out of time to translate the code to use the cell engine because the implementation I had caused texture tearing.
Were the floor/ceiling textures not power-of-two dimensions on each side? As I recall, you only got texture cracking when the dimensions were not power-of-two.
You could have decomposed the floor/ceiling textures into strips as well, but ultimately the lack of perspective correction meant you were going to have to do some heavy lifting somewhere.
I had to write my own string.h ANSI C library because the one 3DO supplied with their compiler had bugs! string.h??? How can you screw that up!?!?! They did! I spent a day writing all of the functions I needed in ARM 6 assembly.
Ah, yes, the Norcroft compiler (or, as I always called it, Norcruft). It was a piece of shit. It was also the only thing available that would run on the Mac. It was never anything but a C compiler, but kept throwing unblockable warnings about constructs that C++ would have problems with (such as implicit cast from void*). There was no MacOS port of GCC, and there were no usable ARM backends for GCC available at the time, anyway. (Bear in mind, this was before the Web existed in any familiar form, and you had to go trawling through USENET for clues -- not even AltaVista existed yet).
I hope that everyone who looks at this code, learns something from it, and I'd be happy to answer questions about the hell I went through to make this game. I only wished I had more time to actually polish this back in 1995 so instead of being the worst port of DOOM, it would have been the best one.
Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
I wanted to chime in and thank everyone for participating in what was clearly an insane exercise in trying to cut through the acrimony and vitriol and get some actual information on what systemd is and what it's trying to do. You can't always grok what complex things are about just from the docs. That's why I wanted actual first-hand experiences from people who could point to actual gems they'd found.
To respond to some recurring remarks throughout the comments:
"Obviously a pro-systemd shill." No, I'm not shilling for RedHat or Poettering. In fact, I gave Poettering some stick for the whole corrupt-binary-logs-aren't-a-bug thing a couple weeks ago. I was being forthright in the opening paragraph: The simple fact that systemd has been widely adopted despite widespread protest made me genuinely wonder what I was missing that I hadn't figured out from the docs I'd read. So, no, there's no conspiracy here.
"Who are you to establish posting rules?" Well, gosh, sorry, but I was trying to save everyone time. Seriously, tell me you haven't gone, "Oh, ${DEITY}, another systemd thread; there goes my afternoon as I pick through the rat's nest of comments." So I hoped -- perhaps naively -- that requesting some organization would let us all get to the meat of issues of interest fairly quickly. And enough people did choose the follow the rules that the discussion overall turned out valuable (for me, anyway).
"Why do you dislike something you admit you know nothing about?" For largely the same reason I dislike Windows without having comprehensively pored over the "design" docs for COM, DCOM, MFC/ATL/WTL, WDM, NTFS, NTLM, Direct${THING}, Active${THING}, etc. etc. etc. Poorly-designed systems seem to have a certain "pattern" to them, and systemd at first glance seemed to match that pattern (the use of Windows-style INI files syntax didn't help, either). But the people adopting systemd are clearly not idiots, so I hoped people with actual experience with the thing could convey insights that (for me) the docs so far have not.
"You're thinking of the ads for Miller Lite, not Bud Light." *headdesk* I would like to apologize to a no doubt deeply irritated TV ad executive for completely misattributing their fifteen-odd years and millions of dollars worth of loud beer ads to the wrong company (I think this speaks well to my socially-isolated geek cred, though:-) ).
In the best tradition of USENET, I thought I'd summarize the highlights of what I got out of the whole thing. Most of the good posts have already been modded up, but the ones that especially stood out for me were these:
http://linux.slashdot.org/comm... , describing that systemd plays nice inside a container, presumably making it easier to create VM-ish setups.
http://linux.slashdot.org/comm... , where the poster describes how systemd does a better job of stopping processes/daemons. The poster then sticks around, giving clear answers to further questions.
http://linux.slashdot.org/comm... , describing how systemd exposes Linux cgroups to create limited execution environments for daemons or (it appears) any process.
Yes, the bricked chips can (allegedly) be restored to working order through the use of a utility. "Hang on. Would this utility be furnished by the very same company that wrecked my device in the first place?" Why yes; is that relevant? "Very fscking hilarious; I'll be looking elsewhere for my USB-serial adapter needs from now on..."
This is a distinction without a difference, as they say. You wouldn't cut any slack to a malware author who tried to claim, "Oh, the files aren't destroyed. They're merely encrypted, and can be restored to their previous condition through the use of this handy-dandy decryption key, available exclusively from me... for a modest fee..."
Assuming FTDI manages to weasel out of lawsuits for willful destruction of property (do NOT let them hide behind the so-called EULA), they have basically made themselves the vendor to avoid for either chips or drivers for said chips.
Can you tell, by merely looking at it, whether a given device is using GenuineFTDI(TM)(R)(C)(BFD) chips, or whether it's a counterfeit? Can you tell by using whatever the Windows equivalent of lsusb is? No? Then there is a random, non-trivial chance that plugging in your serial-ish device will either:
Work (old non-destructive drivers),
Not work (new, non-destructive drivers),
Ruin the device (new, destructive drivers), so that it not only Not Works, but also Stops Working on every other machine on which it previously worked.
Thus, in the mind of the user, FTDI == Flaky. And Flaky == Avoid.
Congratulations, FTDI. Ten points for avoiding your feet, but minus several million for shooting yourself straight in the head.
Every time the systemd thing comes up, I want to hate it, but I don't truly know enough about it to actually hold a defensible opinion.
One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.
Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:
Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:
Well, yeah, corrupt logs would be regarded by many as a major bug...
...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.
Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.
Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.
Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.
Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!
....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.
And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"
File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.
....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr
- the Windows 8 era machines include Windows 7 AND 8 installation disks - choose whatever you like.
If you custom-build a machine from their ZBook "Mobile Workstation" line, you can even configure a machine to not have Windows installed at all. Saves you about $100.00. Still rather pricey, though...
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.
As far as I'm aware, you don't need 'dump' with ZFS. You create a snapshot, then 'zfs send' that snapshot off to your backup storage. Can be done on a live filesystem. Delete the local snapshot when you're done copying it off. ( http://docs.oracle.com/cd/E187... )
Yes. Alas, this is a consequence of ZFS's COW (copy on write) design.
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.
First, a gratuitous plug for my Let's Play/Drown Out video series, currently focusing on 3DO console titles: http://www.youtube.com/playlis...
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 rate
I don't know who the miserable asshat is who keeps front-paging this blithering right-wing horseshit, but they need to be fired yesterday.
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.
Inside Google Play, scroll to the bottom of the app's page. Under the heading, "Permissions," you will find a link named, "View details." Tap on that, and a more familiar list of permissions will appear, including flags on new permissions.
Slashdot Mirror
As it happens, about three years ago I started doing an irregular series of Let's Play/Drown Out videos on YouTube with my colleage, GammaDev. Both of us are former employees of 3DO, and we covered The Deal that Never Happened in a video about two years ago (seek to 25:12).
Frankly, I'm having a hard time seeing how Lenovo recovers from this.
I don't see it unfolding that way. Remember what happened when BitKeeper tried to get up in his business. Linus, if provoked, could write an init/system management framework in a couple weeks (and probably name it "twerp" or some such). And I suspect he would do so long before things got to stage #3, just to prove the point.
C'mon, guys, this is copy-pasted marketing fluff. Better is expected of you.
"Good evening, ladies and gentlemen; some substitutions. Tonight, the role of Genghis Khan will be played by John Wayne."
In that case, why bother with dynamic linking at all? Why not statically link everything? The effect is essentially the same -- you get exactly what the developer had. You also get no shared code pages -- even if you're using exactly the same library as someone else -- and bloated memory and disk usage since you have your own private copy of everything. Disk may be "cheap," but it's still surprisingly easy to fill up a 16GB eMMC device.
"You can update transactionally!!" Great. What does that mean? Is it like git add newapp; git commit -a? If so, how do I back out a program I installed three installations ago?
dpkg -l
dpkg -i <previous_version>
#include <cheap_shots/systemd.h>
debsums
...Did this guy just say he brought DLL Hell to Linux? Help me to understand how he didn't just say that.
No, it isn't!! What the hell is OwnCloud pulling in? What's it using as an HTTP server? As an SSL/TLS stack? Is it the one with the Heartbleed bug, the POODLE bug, or some new bug kluged in by the app vendor to add some pet feature that was rejected from upstream because it was plainly stupid?
Honestly, I'm really not getting this. It just sounds like they created a pile of tools that lets "cloud" administrators be supremely lazy. What am I missing here?
I worked for NTG/3DO for just under five years, so I know (knew) the machine inside and out. It will be interesting to go through this code and see what kind of tradeoffs were made.
Some comments on the README:
*snerk* I could have told you at the time that a ten-week dev cycle was crazy talk.
An interesting and valid approach (3DO's OS had full memory tracking). I'd be interested to know which of the 3DO libs was leaking memory on you.
Were the floor/ceiling textures not power-of-two dimensions on each side? As I recall, you only got texture cracking when the dimensions were not power-of-two.
You could have decomposed the floor/ceiling textures into strips as well, but ultimately the lack of perspective correction meant you were going to have to do some heavy lifting somewhere.
Ah, yes, the Norcroft compiler (or, as I always called it, Norcruft). It was a piece of shit. It was also the only thing available that would run on the Mac. It was never anything but a C compiler, but kept throwing unblockable warnings about constructs that C++ would have problems with (such as implicit cast from void*). There was no MacOS port of GCC, and there were no usable ARM backends for GCC available at the time, anyway. (Bear in mind, this was before the Web existed in any familiar form, and you had to go trawling through USENET for clues -- not even AltaVista existed yet).
I'm sure many memories will come flooding back.
Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
Well... All told, I think that went rather well.
I wanted to chime in and thank everyone for participating in what was clearly an insane exercise in trying to cut through the acrimony and vitriol and get some actual information on what systemd is and what it's trying to do. You can't always grok what complex things are about just from the docs. That's why I wanted actual first-hand experiences from people who could point to actual gems they'd found.
To respond to some recurring remarks throughout the comments:
No, I'm not shilling for RedHat or Poettering. In fact, I gave Poettering some stick for the whole corrupt-binary-logs-aren't-a-bug thing a couple weeks ago. I was being forthright in the opening paragraph: The simple fact that systemd has been widely adopted despite widespread protest made me genuinely wonder what I was missing that I hadn't figured out from the docs I'd read. So, no, there's no conspiracy here.
Well, gosh, sorry, but I was trying to save everyone time. Seriously, tell me you haven't gone, "Oh, ${DEITY}, another systemd thread; there goes my afternoon as I pick through the rat's nest of comments." So I hoped -- perhaps naively -- that requesting some organization would let us all get to the meat of issues of interest fairly quickly. And enough people did choose the follow the rules that the discussion overall turned out valuable (for me, anyway).
For largely the same reason I dislike Windows without having comprehensively pored over the "design" docs for COM, DCOM, MFC/ATL/WTL, WDM, NTFS, NTLM, Direct${THING}, Active${THING}, etc. etc. etc. Poorly-designed systems seem to have a certain "pattern" to them, and systemd at first glance seemed to match that pattern (the use of Windows-style INI files syntax didn't help, either). But the people adopting systemd are clearly not idiots, so I hoped people with actual experience with the thing could convey insights that (for me) the docs so far have not.
*headdesk* I would like to apologize to a no doubt deeply irritated TV ad executive for completely misattributing their fifteen-odd years and millions of dollars worth of loud beer ads to the wrong company (I think this speaks well to my socially-isolated geek cred, though
In the best tradition of USENET, I thought I'd summarize the highlights of what I got out of the whole thing. Most of the good posts have already been modded up, but the ones that especially stood out for me were these:
vi*. Little-endian. Motorola. Amiga. ASCII**. Obviously.
(* with great respect to those who are able to use EMACS well.)
(** Seriously, who not using punched cards ever actually liked EBCDIC?)
Yes, the bricked chips can (allegedly) be restored to working order through the use of a utility. "Hang on. Would this utility be furnished by the very same company that wrecked my device in the first place?" Why yes; is that relevant? "Very fscking hilarious; I'll be looking elsewhere for my USB-serial adapter needs from now on..."
This is a distinction without a difference, as they say. You wouldn't cut any slack to a malware author who tried to claim, "Oh, the files aren't destroyed. They're merely encrypted, and can be restored to their previous condition through the use of this handy-dandy decryption key, available exclusively from me... for a modest fee..."
Can you tell, by merely looking at it, whether a given device is using GenuineFTDI(TM)(R)(C)(BFD) chips, or whether it's a counterfeit? Can you tell by using whatever the Windows equivalent of lsusb is? No? Then there is a random, non-trivial chance that plugging in your serial-ish device will either:
Thus, in the mind of the user, FTDI == Flaky. And Flaky == Avoid.
Congratulations, FTDI. Ten points for avoiding your feet, but minus several million for shooting yourself straight in the head.
One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.
Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:
Well, yeah, corrupt logs would be regarded by many as a major bug...
Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.
Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.
....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.
And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"
....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr
If you custom-build a machine from their ZBook "Mobile Workstation" line, you can even configure a machine to not have Windows installed at all. Saves you about $100.00. Still rather pricey, though...
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.
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.
As far as I'm aware, you don't need 'dump' with ZFS. You create a snapshot, then 'zfs send' that snapshot off to your backup storage. Can be done on a live filesystem. Delete the local snapshot when you're done copying it off. ( http://docs.oracle.com/cd/E187... )
I dunno about ZFS for Linux, but FreeNAS's ZFS has NFSv4 ACLs. Are these not sufficient?
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.
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 rate
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.
Inside Google Play, scroll to the bottom of the app's page. Under the heading, "Permissions," you will find a link named, "View details." Tap on that, and a more familiar list of permissions will appear, including flags on new permissions.
Last snapshot I could find on archive.org: http://web.archive.org/web/200...