... whereas 625 lines at the same frame rate produced 15.625kHz which is inaudible to most adults.
So that's why I can hear a TV from 2 blocks away. I've always been able to hear it, and I could never figure out what in the world I was hearing! It drives me completely batshit insane. (This is why, in fact, I much prefer LCD to CRT - they're quiet!)
BetaMax. Yeah, it really is a shame it didn't make it in the market. It might have helped if they'd designed it for 120+ minute recordings from the start instead of retrofitting it on. Then, perhaps, more movies would have been shipped on it and it've had a fighting chance.
Laserdisc. 3 words: too. fucking. big. They were too big to be really practical, especially when people are getting used to this new-fangled compact disc thing - a little peice of plastic 5" wide instead of this glass plate a goddamn mile wide.
8-track. 2 words: too small. Only 4 tracks, so there wasn't much you could squeeze onto it without putting multiple songs on a track. Recording would have been nice, but IMO, only having 4 tracks when tapes and CDs ended up with 10 or more was kind of a disappointment.
HD audio. One word: market. Only true audiophiles really grasp why HD audio was ever needed to begin with. The fact that this wasn't played up more probably cost it the brief battle it fought. It doesn't help, either, that only DVD players really support SACD or DVD-A, and that for a long time, that support wasn't very common (to my knowledge). I'm not even sure my PS3 (shiny!) supports it. None of the documentation bothers to point it out.
MiniDisc. ATRAC. Need I say more? Audiophiles don't like the fact that it's even compressed, never mind that if you make an MD from MP3s, the transcoding sends it all to shit. The audio quality has a reputation for being terrible because of that. ATRAC killed the MiniDisc. End of story.
BeOS. Indeed, Gassée's greed and the frustrations Be's sales team had in trying to get it pre-installed had a major hand in its death. If they had done x86 and PPC releases together (and, perhaps, implemented a multi-platform extension to all binaries), they might have been able to make a double-pronged attack against Windows and MacOS. The BeBox was a good idea, too, but it was all for naught. These former Apple employees were way too late in the game, IMO. A damn shame, too. I'd rather have grown up with BeOS instead of Windows.
DTS. I'm completely unfamiliar with the format, so I'll just skip it...
Atari ST. Honestly, I don't see what the fuss is about. Anyone who's spent any time on an Amiga knows that everything pales in comparison: High-resolution color displays with support for up to 4096-color pallettes (HAL mode - really just a set of 16 256-color pallettes, set per-scanline) and a multi-resolution display mode (literally, sequential scanlines changed to different display modes and resolutions) provided by Fast Copper, a custom high-quality 4-channel audio chip with hardware mixing, and an innovative take on the WIMP concept years ahead of anything else on the market.... Commodore just didn't know what they had, didn't market it, and went the way of all mis-managed companies, and the personal computer market lost the best hardware of its day. The Atari, by comparison, is a joke.
I wanna know what those shitheads are smoking. It must be some nice shit if they can be this stupid.
It's a myth that one must install 3rd party software to get a DSL or Cable modem activated.
Of this I'm quite aware. However, my activation wasn't so painless: It took 3 days to get it activated, after 5 total hours on the phone. Evidently, the service was incompetently "set up" at their end, and a series of stupid mistakes had to be undone before the modem would finally connect.
Ogg Theora video, Ogg (Vorbis?) audio, OGM or MKV containers. AFAIK these are the only credible, totally open formats that don't require any licensing etc. IIRC the BBC came up with another ogg video format, Dirac, which might also qualify. But there are probably others - the issue is that players and encoders for these are fairly readily available. Hopefully someone else will chime in with more?
AFAIK, OGM is a modified Ogg container, with its header modified to be compatible with AVI so that Windows Media Player doesn't completely choke on it. I could be mistaken, but that's what I've heard.
Unfortunately, I know of no hardware supporting Theora, nor do I know of any software outside the world of Linux where Theora is supported - the codec for Windows was horribly broken, last I checked. VLC, however, does support it.
Vorbis (in the Ogg container) is supported only by a handful of players, and these include iRiver's Clix line and a number of Samsung Yepp models. Nearly everything else that plays more than one format supports either MP3 and WMA or MP3 and AAC.
It's required to "register" the connection. Once you've activated it, it serves out DHCP requests just fine. It's just that whole "registering" business they require IE for.
No, they don't give a crap. Isometimes have trouble with it myself, and when I do, I just use Opera or Konqueror instead. (I'm actually using Firefox less and less these days.) I have IE installed (on Linux!) just for these kinds of situations, but I have yet no need for it.
I actually had a guy come in to set up Comcast last year, and he brought with him a CD. Evidently, Comcast gives its poorly-trained techs a CD that they just pop into a Windows system, and it automatically configures the network settings. He was completely dumbfounded when he found out I use Linux:
Him: So, do you have Internet Explorer on that thing? Me: Well, sorta. *Starts IE 6 in Wine.* Him: *Puts CD in. Nothing happens. Look of confusion.* Me: It doesn't autorun. Lesse... *Runs software in Wine. It starts, but is obviously broken.* Well, can't use this. What network settings do I need to configure? Him: I don't know. I don't understand. Usually, I just put the CD in and it works. Me: Yeah, well, this is Linux. Him: *Look of confusion.* Me: Yeah, I don't have Windows. Him: Well, we can't do this without.
So I ended up spending the next 3 days on the phone talking to support, trying to get them to register the connection on their end. It works fine now, but all the configuration and registration of the connection is done on the customer side... It seems they set the IP to something non-routable (might be 76.x.x.x, not sure), exchange a few packets with the DHCP server, then it "registers" the cable connection with DHCP and it begins sending out leases.
As much as I hate what's become of the title "hacker," I still love it when I'm walking down the street wearing my "hacker." t-shirt from ThinkGeek.
On sidewalks, I'm given a wide berth.
In stores, I'm carefully watched, but all the clerks are extremely friendly and very helpful. (I can usually get retail shopping done quicker and more efficiently.)
Even restaurants and fast food places seem more concerned about my personal satisfaction.
Locks suck. Nobody really understands efficient locking schemes. You either wind up with (a) a system with a few giant locks, and little parallelism, or (b) a system with lots of locks, but also lots of crashes and deadlocks. Very few programmers can deal with this stuff.
Mostly because it's simply not taught in lower-level CS courses, nor is it really encouraged on the most popular platforms.
I can't wrap my head around this stuff, because I can't find anything helpful. All I ever see documented is "Here is how to create a thread," or "Here is how to fork()," (the stuff any child with an API doc already knows) or "System and method for lockless data structures." (Which is only actually readable by CS PhDs.) NEVER do I see anything that says "Now that you know how to fork threads, here is how they can share data without directly causing the coming of Armageddon," or even "What NOT to do with mutexes."
There's little instructional material online, and what there is is either too advanced for someone just trying to wrap their head around it or simply an inadequate discussion of the topic. (The same is true of BSD sockets, but that's OT for now.)
Any sufficiently advanced technology is insufficiently documented.
That's not quite what I'm asking. All you're describing is the function of a simple fork().
What I'm interested in is full-blown in-process threading, where I break off parallel sections of (for example) a large C++ framework that operate on shared chunks of data.
I already understand what threads are and how to create them. I just don't understand locking mechanisms. I mean, conceptually, sure, I understand that in one locking model, one thread locks a mutex and other threads will block if they try to lock the same mutex. But I want to understand semaphores and lockless structures on more than a merely conceptual level, and I've found little beyond a few theoretical items or white papers - stuff that was frankly over my head.
I'm simply not interested in implementing this kind of thing in PHP - that's child's play. I've got a project I'm writing in C++ that I want to thread properly. I just don't know how to do it without making a huge mess of things.
See the thing is, I keep upgrading machines, 1ghz, 2ghz, 3ghz, 3ghz dual core, 512mb, 1gb, 2gb - etc
The user interface is laggy
EVER so slightly laggy but laggy, there's this 'engine' underneath the hood, since the days of 95 (yes 95) where it just feels wrong, it feels like the same code to be honest from version to version?
It's a ridiculous claim, have no doubt, I realise that but god-damnit it just seems that way.
I'll give a simple example of why this may be so:
Run any version of windows on an emulator - a *very* slow one. (A good example is a 486 emulator running on an Amiga 3000 - one that reports itself as being a 486DX4-16.) And I don't mean sluggish, I mean painfully slow.
What you're likely to see when a window is created is this: First, the rectangular border is drawn. Second, the title bar is drawn, but no text filled in. Third, the border is erased and redrawn. Text is filled in in the title bar, then the border again erased and redrawn. When you resize a window, you'll likely get to watch the border get erased, drawn in the new position, the nerased and redrawn while the program begins drawing its window's contents.
The UI is horribly inefficient for several reasons, and I seriously doubt it's been properly fixed before Vista, since 3.0. I truly suspect you'll see similar behavior on the standard UI widgets as well.
(This process was described to me by a friend after he ran Windows on his Amiga's PC emulator. We laughed then, but it made me feel sick inside. Why not just draw it once and be done with it?)
How can programmers like me (I have only had very limited threading experience, mostly due to the many pitfalls of doing it right - I'm lazy and stupid) get the training and education we desperately need to do multithreading right? Multithreading can never become pervasive, IMO, until everyone is properly educated on it.
So where do I go? What do I need to do? I want to learn this stuff. I need to learn this stuff. And most importantly, I want to do it right.
All of the other code I write is as damn near bug-free as I'm capable - I want to be equally proficient with threading and locking, because until then, I may as well still be in my diapers hacking assembly on a 6502.
I want to be a better programmer, and so far, this is my only roadblock.
Not my coffee shop. The only sugar they usually serve is "Sugar in the Raw," and the coffee syrups? Not very popular. It covers up the artistic experience that is the coffee.
Con sees problems in the process scheduler. He knows no one else will fix it, so he takes a little bit of free time from being a medical practitioner to hunkerdown and figure out how to "fix" the scheduler. He does so. He succeeds in improving the interactivity of Linux 2.4-based systems. 2.5 becomes 2.6, and Con moves his efforts there, trying to get Ingo to accept his new scheduler design. Ingo writes the "O(1) scheduler." Con keeps improving his staircase design, still trying to get Ingo to give it a chance. Years pass.
Con finally convinces a number of kernel devs to see that the existing scheduler sucks and that Staircase is a vast improvement. Ingo writes CFS. 4 weeks later, he effectively declares CFS to be "done" and ready for the kernel.
Con has spent YEARS working to perfect his scheduler design. Now, finally, people are taking his approach seriously, and Ingo undercuts him by putting his scheduler in the kernel and not Con's.
Con is very obviously sick of the bullshit. He's tired of trying, and it's adversely affecting his health. He was bedridden and still managed to fix what few bugs had shown up in his latest RSDL implementation. And Ingo is merging code a few weeks old? A still-flawed design that hasn't been tested enough?
This is UNFAIR. Both to Con and to users of Linux. Con has been getting the short end of the stick for far too long.
What I think the appropriate attribution should be is this: Ingo should flatly state that CFS is a rip-off of RSDL. He should admit that the only reason CFS exists is because of Con's RSDL. Ingo should admit that CFS is young and poorly tested and that RSDL is a mature, solid, well-tested design. Con didn't "pioneer the fair scheduling approach." Con opened Ingo's eyes to the fact that the old scheduler is a piece of shit.
Ingo should get on his knees and worship at the shrine of Con Kolivas.
How is it the will of the artists when NiN were stunned to discover that stores were charging a $10 premium on their new CD (Year Zero) simply because they're NiN? They don't get a single penny of that $10 premium.
People have successfully modded it to play PS2 "backups," and the only failures have been the BD-ROM drive breaking itself if you mismatch your backup disk with the game disk you're swapping it for.
Beyond that, the only failure I've heard of was when some paranoid kid wanted to protect his shiny new PS3 from getting dust inside - so he covered the vents with duct tape.
Ingo's posts could explain far better than I. Suffice to say, a running task won't be starved CPU just because another process has come along to snatch it away. The previous scheduler didn't do this, and seemed to favor processes that needed far less CPU.
That's precisely what he's been doing for years, and he's all but given up on it because of all of his failed attempts to get the kernel devs to look at his code. It's only in the last few months that Ingo bothered to take Con's ideas seriously.
The G80 chips are general-purpose highly-parallel number-crunchers. Remember the Cell/BE processor? Scale the SPEs down to about half the instruction set with a small register bank. Put 48 of them on one chip.
It works quite well. I use Con Kolivas' SD scheduler (on which CFS is based), and in a similar situation (with heavy I/O and numerous power-hungry apps), it performs exceedingly well.
Ingo tests CFS with a kernel make -j50 - just to give you an idea of what we're shooting for here.
Actually, no, Gnome and KDE aren't the troublemakers. It turns out that certain X drivers are poorly written and X preempts processes vying for CPU. CFS helps improve the situation - almost to the point where you don't notice it.
Slashdot Mirror
So that's why I can hear a TV from 2 blocks away. I've always been able to hear it, and I could never figure out what in the world I was hearing! It drives me completely batshit insane. (This is why, in fact, I much prefer LCD to CRT - they're quiet!)
I wanna know what those shitheads are smoking. It must be some nice shit if they can be this stupid.
Of this I'm quite aware. However, my activation wasn't so painless: It took 3 days to get it activated, after 5 total hours on the phone. Evidently, the service was incompetently "set up" at their end, and a series of stupid mistakes had to be undone before the modem would finally connect.
Didn't you RTFS? They have jobs. In fact, they're self-employed.
I wish I'd had that kind of enthusiasm with my youthful business ventures.
AFAIK, OGM is a modified Ogg container, with its header modified to be compatible with AVI so that Windows Media Player doesn't completely choke on it. I could be mistaken, but that's what I've heard.
Unfortunately, I know of no hardware supporting Theora, nor do I know of any software outside the world of Linux where Theora is supported - the codec for Windows was horribly broken, last I checked. VLC, however, does support it.
Vorbis (in the Ogg container) is supported only by a handful of players, and these include iRiver's Clix line and a number of Samsung Yepp models. Nearly everything else that plays more than one format supports either MP3 and WMA or MP3 and AAC.
Positive.
It's required to "register" the connection. Once you've activated it, it serves out DHCP requests just fine. It's just that whole "registering" business they require IE for.
No, they don't give a crap. Isometimes have trouble with it myself, and when I do, I just use Opera or Konqueror instead. (I'm actually using Firefox less and less these days.) I have IE installed (on Linux!) just for these kinds of situations, but I have yet no need for it.
I actually had a guy come in to set up Comcast last year, and he brought with him a CD. Evidently, Comcast gives its poorly-trained techs a CD that they just pop into a Windows system, and it automatically configures the network settings. He was completely dumbfounded when he found out I use Linux:
Him: So, do you have Internet Explorer on that thing?
Me: Well, sorta. *Starts IE 6 in Wine.*
Him: *Puts CD in. Nothing happens. Look of confusion.*
Me: It doesn't autorun. Lesse... *Runs software in Wine. It starts, but is obviously broken.* Well, can't use this. What network settings do I need to configure?
Him: I don't know. I don't understand. Usually, I just put the CD in and it works.
Me: Yeah, well, this is Linux.
Him: *Look of confusion.*
Me: Yeah, I don't have Windows.
Him: Well, we can't do this without.
So I ended up spending the next 3 days on the phone talking to support, trying to get them to register the connection on their end. It works fine now, but all the configuration and registration of the connection is done on the customer side... It seems they set the IP to something non-routable (might be 76.x.x.x, not sure), exchange a few packets with the DHCP server, then it "registers" the cable connection with DHCP and it begins sending out leases.
And, of course, the CD requires admin rights.
As much as I hate what's become of the title "hacker," I still love it when I'm walking down the street wearing my "hacker." t-shirt from ThinkGeek.
On sidewalks, I'm given a wide berth.
In stores, I'm carefully watched, but all the clerks are extremely friendly and very helpful. (I can usually get retail shopping done quicker and more efficiently.)
Even restaurants and fast food places seem more concerned about my personal satisfaction.
These people are scared of hackers.
Mostly because it's simply not taught in lower-level CS courses, nor is it really encouraged on the most popular platforms.
I can't wrap my head around this stuff, because I can't find anything helpful. All I ever see documented is "Here is how to create a thread," or "Here is how to fork()," (the stuff any child with an API doc already knows) or "System and method for lockless data structures." (Which is only actually readable by CS PhDs.) NEVER do I see anything that says "Now that you know how to fork threads, here is how they can share data without directly causing the coming of Armageddon," or even "What NOT to do with mutexes."
There's little instructional material online, and what there is is either too advanced for someone just trying to wrap their head around it or simply an inadequate discussion of the topic. (The same is true of BSD sockets, but that's OT for now.)
Yeah, like threading APIs.
That's not quite what I'm asking. All you're describing is the function of a simple fork().
What I'm interested in is full-blown in-process threading, where I break off parallel sections of (for example) a large C++ framework that operate on shared chunks of data.
I already understand what threads are and how to create them. I just don't understand locking mechanisms. I mean, conceptually, sure, I understand that in one locking model, one thread locks a mutex and other threads will block if they try to lock the same mutex. But I want to understand semaphores and lockless structures on more than a merely conceptual level, and I've found little beyond a few theoretical items or white papers - stuff that was frankly over my head.
I'm simply not interested in implementing this kind of thing in PHP - that's child's play. I've got a project I'm writing in C++ that I want to thread properly. I just don't know how to do it without making a huge mess of things.
I'll give a simple example of why this may be so:
Run any version of windows on an emulator - a *very* slow one. (A good example is a 486 emulator running on an Amiga 3000 - one that reports itself as being a 486DX4-16.) And I don't mean sluggish, I mean painfully slow.
What you're likely to see when a window is created is this: First, the rectangular border is drawn. Second, the title bar is drawn, but no text filled in. Third, the border is erased and redrawn. Text is filled in in the title bar, then the border again erased and redrawn. When you resize a window, you'll likely get to watch the border get erased, drawn in the new position, the nerased and redrawn while the program begins drawing its window's contents.
The UI is horribly inefficient for several reasons, and I seriously doubt it's been properly fixed before Vista, since 3.0. I truly suspect you'll see similar behavior on the standard UI widgets as well.
(This process was described to me by a friend after he ran Windows on his Amiga's PC emulator. We laughed then, but it made me feel sick inside. Why not just draw it once and be done with it?)
How can programmers like me (I have only had very limited threading experience, mostly due to the many pitfalls of doing it right - I'm lazy and stupid) get the training and education we desperately need to do multithreading right? Multithreading can never become pervasive, IMO, until everyone is properly educated on it.
So where do I go? What do I need to do? I want to learn this stuff. I need to learn this stuff. And most importantly, I want to do it right.
All of the other code I write is as damn near bug-free as I'm capable - I want to be equally proficient with threading and locking, because until then, I may as well still be in my diapers hacking assembly on a 6502.
I want to be a better programmer, and so far, this is my only roadblock.
Not my coffee shop. The only sugar they usually serve is "Sugar in the Raw," and the coffee syrups? Not very popular. It covers up the artistic experience that is the coffee.
Here's how I see it:
Con sees problems in the process scheduler. He knows no one else will fix it, so he takes a little bit of free time from being a medical practitioner to hunkerdown and figure out how to "fix" the scheduler. He does so. He succeeds in improving the interactivity of Linux 2.4-based systems. 2.5 becomes 2.6, and Con moves his efforts there, trying to get Ingo to accept his new scheduler design. Ingo writes the "O(1) scheduler." Con keeps improving his staircase design, still trying to get Ingo to give it a chance. Years pass.
Con finally convinces a number of kernel devs to see that the existing scheduler sucks and that Staircase is a vast improvement. Ingo writes CFS. 4 weeks later, he effectively declares CFS to be "done" and ready for the kernel.
Con has spent YEARS working to perfect his scheduler design. Now, finally, people are taking his approach seriously, and Ingo undercuts him by putting his scheduler in the kernel and not Con's.
Con is very obviously sick of the bullshit. He's tired of trying, and it's adversely affecting his health. He was bedridden and still managed to fix what few bugs had shown up in his latest RSDL implementation. And Ingo is merging code a few weeks old? A still-flawed design that hasn't been tested enough?
This is UNFAIR. Both to Con and to users of Linux. Con has been getting the short end of the stick for far too long.
What I think the appropriate attribution should be is this: Ingo should flatly state that CFS is a rip-off of RSDL. He should admit that the only reason CFS exists is because of Con's RSDL. Ingo should admit that CFS is young and poorly tested and that RSDL is a mature, solid, well-tested design. Con didn't "pioneer the fair scheduling approach." Con opened Ingo's eyes to the fact that the old scheduler is a piece of shit.
Ingo should get on his knees and worship at the shrine of Con Kolivas.
Yes, I'm bitter. I'm sick of watching this.
No, apparently, it's the labels setting the premium, despite NiN's protests - and they're *VERY MUCH* looking forward to the end of their contract.
How is it the will of the artists when NiN were stunned to discover that stores were charging a $10 premium on their new CD (Year Zero) simply because they're NiN? They don't get a single penny of that $10 premium.
Imagine if they used Excel to calculate what goes into that syringe.
People have successfully modded it to play PS2 "backups," and the only failures have been the BD-ROM drive breaking itself if you mismatch your backup disk with the game disk you're swapping it for.
Beyond that, the only failure I've heard of was when some paranoid kid wanted to protect his shiny new PS3 from getting dust inside - so he covered the vents with duct tape.
Ingo's posts could explain far better than I. Suffice to say, a running task won't be starved CPU just because another process has come along to snatch it away. The previous scheduler didn't do this, and seemed to favor processes that needed far less CPU.
That's precisely what he's been doing for years, and he's all but given up on it because of all of his failed attempts to get the kernel devs to look at his code. It's only in the last few months that Ingo bothered to take Con's ideas seriously.
Your whites.
The G80 chips are general-purpose highly-parallel number-crunchers. Remember the Cell/BE processor? Scale the SPEs down to about half the instruction set with a small register bank. Put 48 of them on one chip.
It'll do your laundry.
It works quite well. I use Con Kolivas' SD scheduler (on which CFS is based), and in a similar situation (with heavy I/O and numerous power-hungry apps), it performs exceedingly well.
Ingo tests CFS with a kernel make -j50 - just to give you an idea of what we're shooting for here.
Actually, no, Gnome and KDE aren't the troublemakers. It turns out that certain X drivers are poorly written and X preempts processes vying for CPU. CFS helps improve the situation - almost to the point where you don't notice it.