The only devices that should need to worry about this patent are things like MP3 players that display the filenames themselves. Most of these show ID3 tags before filenames, obviating some of the need for it.
Off the main topic, but DV breaks the timing limits from film. With an external battery pack, you can shoot all the way to the end of a tape in one shot. Timecode was a conceptually cool pic from a few years ago. The basic story was simple, Selma Hayek was a wannabe star, sleeping around to get a role. Jeane Tripplehorn her jealous lover who chases her, and ends up shooting the director she was sleeping with.
The story wasn't much special, but the shooting consisted of a bunch of Sony DVs (I think around 13) with one tape, and they shot one take, one shot, all the way through the end of the tape, following people around. At any time they had up to 4 video streams on screen, and 2 audio streams. They'd switch the video streams when they found somehting interesting, which unfortunately wasn't as many as you'd think, especially considering it had Hayek and Tripplehorn in a lesbian relationship. Having the 13 or so streams at least broke up the monotony of what a single take for 100 minutes would entail. The multiple audio actually was much harder than the multiple video to process. At the end, all 4 cams were in the same room, getting multiple angles of the scene.
Since it was just Sony VX1000s, there wasn't a lot of gear. I heard that Selma Hayek was walking on the street, doing a take, and people didn't notice that they were filming, and came up for autographs while they shot.
MacOS has always had a virus scanner, even though most viruses were for Windows. Disenfectant was written by John Norstad at Northwestern UNiversity. Great freeware app, and protected agasint all known mac viruses, of there were literally on the order of 20 or so (while there were thousands of Windows ones). The best part was the Monty Python foot that came down in the About Box.
Anyways, here's a story I know. Long time ago, back in the original Pentium divide bug days, some guy had a Pentium machine with the bug, and wanted to replace the CPU. Since the CPU was hundreds of dollars, he had to send in the bad one before he could get the new one. No problem, since they just came out with the new Zero Insertion Force sockets. He tries to pull it out, but he can't. Turns out the manufacturer had glued it in. Seems that people in the loading dock found out that Zero Insertion Force meant also Zero Removal Force and stole the chips, necessitating the glue. What to do, what to do... Then he remembers, "Hey, this is a Pentium isn't it". He removes the heatsink, and runs his computer. CPU gets so hot it melts the glue, and he pulls it out. Don't have to worry about thermal failure anyway, since it's destined for the scrap heap. Sends it back, gets his CPU.
Though my chinese is VERY limited, I think Xi is more often pronounced like "sh". The word is pronounced to rhyme with "now". Xiao means "small" and Taiwanese folks actually write the same word as "shao".
Re:Or... You could do it properly.
on
Optimizing distcc
·
· Score: 1
Anyone remember IBM & Peace Love Linux? Got into some static in San Francisco over it. Unfortunately, some folks really believe the junk about "it's better to ask forgiveness than approval"
Jokes aside, that's essentially what the first AT&T lawsuit did... it sued BSD because they released source code and that lowered the value of UNIX with a (TM), when major portions that made UNIX with a (TM) useful were actually made by BSD.
It sounds like he might want to look into Project UDI. It's a device driver abstraction that allows source and to some level binary compatible device drivers across platforms with the UDI environment. I did a little work in it, and from a very top level look at his kernel threading model, looks like a good fit with how UDI does things. It's not very well known, and being a Caldera/NewSCO type thing (developed initially way before the current management started the legal stuff) now has political baggage as well.
If they're running Linux on anything (desktop, server, game cube, vibrating butt plug - it's been ported, whatever)
I for one am very glad I've switched from Microsoft vibrating butt-plug to a Linux butt-plug. I used to get BSODs 2 or 3 times a day with the Microsoft one, and hitting Ctrl-Alt-Del on that by yourself is no fun trick I tell you. It's funny how few of my geek friends would help me reset it either... weird.
When RedHat decided to release the 7.0 distro, they decided that 2.95 was too broken to serve as their system compiler. Too much C++ stuff was broken, not ANSI compliant, etc. So they grabbed a dev branch of 3.0 (at that time tagged 2.96) polished it, and called it gcc 2.96. Cool in some ways, because it was the first time the rubber hit the road for the 3.x branch. A lot of bugs got fixed. But it was a dev branch, and the code changed on the way to 3.0. So now you have a compiler that is C++ binary incompatible with anything before it, or anything agasint it. RedHat 7.x users (we support it at work) find it real hard to get 3rd party binaries compiled by 7.3. Either they use the more common 2.95, or they're finally trickling in to 3.2 or above (which are finally C++ binary compatible). Just a real PITA getting any C++ code using 2.96.
Interesting: GNU/K{Free,Net}BSD support.
on
XFree86 4.4 Released
·
· Score: 0, Troll
I saw this in the release notes.
Pseudo-intelligent comment: Interesting. My impression of the GNU/*BSDs were that they were an exercise to prove GNU software was more important than Linux. As such GPL licensing issues are critical. I'm surprised they'll accept 4.4 because of licensing issues.
Flammable comment: I'm sure all 6 of the general users that run KFreeBSD will be very happy.
Actually, I see it the other way... sutomating GUI apps via macros is a kludge that is necessary when the apps don't have a powerful command-line interface... which most Linux apps have.
I disagree, at least I don't think that's a universal answer. Macro languages allow you to make automated decisions based on current program state. Command line interfaces only allow control based on initial program state. Sometimes you don't care about the distinction, but it's still a very powerful difference. Macro languages aren't necessarily tied to GUIs either, just are more necessary because there's generally no other way to automate them.
Nice sig BTW. I'm reminded about the/. recent story where some firmware blew acted weird because they couldn't recognize Feb 29 as a leap-day.
Minor quibble... Apple Events are the things that controlled your program. AppleScript is just a language binding (I believe there are others now). But I always loved AppleScript/Apple Events. Very cool tech ahead of it's time. True AppleEvent capable programs actually had a detachment between the menu/GUI interface and the underlying code. The GUI code just sent AppleEvents for every GUI action. The advantage to this? Now your app was recordable, you could record every action you took in your porgram, then automate it (essentially short circuiting the GUI part and just doing it programmatically).
Not to start a flamewar, but I don't know why there are such a bunch of people who believe the command line is the UI that gives ultimate control (I won't go into usability issues) and dismiss macro programs. Command Line interfaces only allow control at app startup, whereas macros that can control deep event models (like AppleEvents/AppleScript) can control program state over the life of the app. Very powerful.
KDE is trying to bring some of this with DCOP. It still seems pretty immature, but looks cool.
Not to start a flamewar, but I think this is a bad answer. You're saying that "UNIX is like this" when really what it is "Linux is like this now". Typically, UNIX has been by and for geeks, which explains it's heavy weighting towards command line solutions. That's not the way it has to be, MacOS X has changed what UNIX has to be.
Macro languages an infection? You're actually giving away a lot of power. Macro programs aren't just for n00bz. True macro languages also have conditionals. This allows smart control over the programs state at all times, whereas command line interfaces only allow it at program startup. You're giving away a lot of control, but it seems saying it's bad to have that control because some people find that control easier. Apple got it right with Apple Events in System 7 in later. You got a framework for consistent representation of program state and actions. AppleScript was the first programming language, but now other langauges have bindings, and I believe AppleScript has fallen out of favor for MacOS X.
A better answer would have been: macro languages in general are only useful when the applications export their functionality in a consistent manner that can be easily used. It's easy for programs to hook into Windows event loops or access Apple Events because of their API consistency. UNIX/Linux just doesn't have that tradition, though it's improving with KDE/Qt with DCOP and multiple languages with DCOP bindings. GNOME probably has this too, but I don't know much about it.
Hmm, that last paragraph was too technical. Maybe, more simply: "Linux doesn't have the required amount of consistency yet, but as soon as geeks realize it's cool to be able to have macros that control multiple programs, we'll have the hooks written in a week. =)"
If it weren't for the Mach micokernel from Apple Mach is from Carnegie Mellon, by way of NeXT.
Windows NT / 2000 / XP runs on a variant of the Mach kernel. XP does not run on Mach. It was a microkernel, made with a lot of input from DEC VAX guys. Over the years it has shed a lot of Microkernel attributes and become more of a macro style kernel.
Mach is a fairly standard, well documented design principal. Microkernels are a fairly standard, well documented, design principal. Mach is an instance of them.
I actually agree with some of your other statements, your parent poster was an uninformed fanboy. Apple has contributed to BSD though, check out the BSD project list and see where.
Slashdot Mirror
Actually, bugzilla beat MS to it.
You mean the Vigor Project?
The only devices that should need to worry about this patent are things like MP3 players that display the filenames themselves.
Most of these show ID3 tags before filenames, obviating some of the need for it.
Good ... we'll have a miracle hybrid with the loyalty of a cat and the cleanliness of a dog!
-- Homer J Simspon.
Off the main topic, but DV breaks the timing limits from film. With an external battery pack, you can shoot all the way to the end of a tape in one shot. Timecode was a conceptually cool pic from a few years ago. The basic story was simple, Selma Hayek was a wannabe star, sleeping around to get a role. Jeane Tripplehorn her jealous lover who chases her, and ends up shooting the director she was sleeping with.
The story wasn't much special, but the shooting consisted of a bunch of Sony DVs (I think around 13) with one tape, and they shot one take, one shot, all the way through the end of the tape, following people around. At any time they had up to 4 video streams on screen, and 2 audio streams. They'd switch the video streams when they found somehting interesting, which unfortunately wasn't as many as you'd think, especially considering it had Hayek and Tripplehorn in a lesbian relationship. Having the 13 or so streams at least broke up the monotony of what a single take for 100 minutes would entail. The multiple audio actually was much harder than the multiple video to process. At the end, all 4 cams were in the same room, getting multiple angles of the scene.
Since it was just Sony VX1000s, there wasn't a lot of gear. I heard that Selma Hayek was walking on the street, doing a take, and people didn't notice that they were filming, and came up for autographs while they shot.
Yes, this is a troll, but Win2K does not have a AMD64 build. Even Current win2002 is beta on AMD64
MacOS has always had a virus scanner, even though most viruses were for Windows. Disenfectant was written by John Norstad at Northwestern UNiversity. Great freeware app, and protected agasint all known mac viruses, of there were literally on the order of 20 or so (while there were thousands of Windows ones). The best part was the Monty Python foot that came down in the About Box.
Do they have a Pentium-4 without a heat sink?
Anyways, here's a story I know.
Long time ago, back in the original Pentium divide bug days, some guy had a Pentium machine with the bug, and wanted to replace the CPU. Since the CPU was hundreds of dollars, he had to send in the bad one before he could get the new one. No problem, since they just came out with the new Zero Insertion Force sockets. He tries to pull it out, but he can't. Turns out the manufacturer had glued it in. Seems that people in the loading dock found out that Zero Insertion Force meant also Zero Removal Force and stole the chips, necessitating the glue. What to do, what to do...
Then he remembers, "Hey, this is a Pentium isn't it". He removes the heatsink, and runs his computer. CPU gets so hot it melts the glue, and he pulls it out. Don't have to worry about thermal failure anyway, since it's destined for the scrap heap. Sends it back, gets his CPU.
Though my chinese is VERY limited, I think Xi is more often pronounced like "sh". The word is pronounced to rhyme with "now".
Xiao means "small" and Taiwanese folks actually write the same word as "shao".
British slang.
s/a doddle to/a piece of cake to/g
Anyone remember IBM & Peace Love Linux? Got into some static in San Francisco over it. Unfortunately, some folks really believe the junk about "it's better to ask forgiveness than approval"
Jokes aside, that's essentially what the first AT&T lawsuit did... it sued BSD because they released source code and that lowered the value of UNIX with a (TM), when major portions that made UNIX with a (TM) useful were actually made by BSD.
It sounds like he might want to look into Project UDI. It's a device driver abstraction that allows source and to some level binary compatible device drivers across platforms with the UDI environment. I did a little work in it, and from a very top level look at his kernel threading model, looks like a good fit with how UDI does things. It's not very well known, and being a Caldera/NewSCO type thing (developed initially way before the current management started the legal stuff) now has political baggage as well.
Any links on the fallout? I did a google on Provos, found a lot of stuff (he would be a loss to any project) but nothing about the split.
International Business Machines? If you can break the sequence for I, I can break it for M. =)
If they're running Linux on anything (desktop, server, game cube, vibrating butt plug - it's been ported, whatever)
I for one am very glad I've switched from Microsoft vibrating butt-plug to a Linux butt-plug. I used to get BSODs 2 or 3 times a day with the Microsoft one, and hitting Ctrl-Alt-Del on that by yourself is no fun trick I tell you. It's funny how few of my geek friends would help me reset it either... weird.
When RedHat decided to release the 7.0 distro, they decided that 2.95 was too broken to serve as their system compiler. Too much C++ stuff was broken, not ANSI compliant, etc. So they grabbed a dev branch of 3.0 (at that time tagged 2.96) polished it, and called it gcc 2.96. Cool in some ways, because it was the first time the rubber hit the road for the 3.x branch. A lot of bugs got fixed. But it was a dev branch, and the code changed on the way to 3.0. So now you have a compiler that is C++ binary incompatible with anything before it, or anything agasint it. RedHat 7.x users (we support it at work) find it real hard to get 3rd party binaries compiled by 7.3. Either they use the more common 2.95, or they're finally trickling in to 3.2 or above (which are finally C++ binary compatible). Just a real PITA getting any C++ code using 2.96.
I saw this in the release notes.
Pseudo-intelligent comment:
Interesting. My impression of the GNU/*BSDs were that they were an exercise to prove GNU software was more important than Linux. As such GPL licensing issues are critical. I'm surprised they'll accept 4.4 because of licensing issues.
Flammable comment:
I'm sure all 6 of the general users that run KFreeBSD will be very happy.
The grass is always greener... Or more basically, humans are never satisfied.
Actually, I see it the other way... sutomating GUI apps via macros is a kludge that is necessary when the apps don't have a powerful command-line interface... which most Linux apps have.
/. recent story where some firmware blew acted weird because they couldn't recognize Feb 29 as a leap-day.
I disagree, at least I don't think that's a universal answer. Macro languages allow you to make automated decisions based on current program state. Command line interfaces only allow control based on initial program state. Sometimes you don't care about the distinction, but it's still a very powerful difference. Macro languages aren't necessarily tied to GUIs either, just are more necessary because there's generally no other way to automate them.
Nice sig BTW. I'm reminded about the
You mean there is a use for WSH besides sending out macro viruses? This should be front page news!!!
Minor quibble... Apple Events are the things that controlled your program. AppleScript is just a language binding (I believe there are others now). But I always loved AppleScript/Apple Events. Very cool tech ahead of it's time. True AppleEvent capable programs actually had a detachment between the menu/GUI interface and the underlying code. The GUI code just sent AppleEvents for every GUI action. The advantage to this? Now your app was recordable, you could record every action you took in your porgram, then automate it (essentially short circuiting the GUI part and just doing it programmatically).
Not to start a flamewar, but I don't know why there are such a bunch of people who believe the command line is the UI that gives ultimate control (I won't go into usability issues) and dismiss macro programs. Command Line interfaces only allow control at app startup, whereas macros that can control deep event models (like AppleEvents/AppleScript) can control program state over the life of the app. Very powerful.
KDE is trying to bring some of this with DCOP. It still seems pretty immature, but looks cool.
Not to start a flamewar, but I think this is a bad answer. You're saying that "UNIX is like this" when really what it is "Linux is like this now". Typically, UNIX has been by and for geeks, which explains it's heavy weighting towards command line solutions. That's not the way it has to be, MacOS X has changed what UNIX has to be.
Macro languages an infection? You're actually giving away a lot of power. Macro programs aren't just for n00bz. True macro languages also have conditionals. This allows smart control over the programs state at all times, whereas command line interfaces only allow it at program startup. You're giving away a lot of control, but it seems saying it's bad to have that control because some people find that control easier. Apple got it right with Apple Events in System 7 in later. You got a framework for consistent representation of program state and actions. AppleScript was the first programming language, but now other langauges have bindings, and I believe AppleScript has fallen out of favor for MacOS X.
A better answer would have been: macro languages in general are only useful when the applications export their functionality in a consistent manner that can be easily used. It's easy for programs to hook into Windows event loops or access Apple Events because of their API consistency. UNIX/Linux just doesn't have that tradition, though it's improving with KDE/Qt with DCOP and multiple languages with DCOP bindings. GNOME probably has this too, but I don't know much about it.
Hmm, that last paragraph was too technical. Maybe, more simply: "Linux doesn't have the required amount of consistency yet, but as soon as geeks realize it's cool to be able to have macros that control multiple programs, we'll have the hooks written in a week. =)"
If it weren't for the Mach micokernel from Apple
Mach is from Carnegie Mellon, by way of NeXT.
Windows NT / 2000 / XP runs on a variant of the Mach kernel.
XP does not run on Mach. It was a microkernel, made with a lot of input from DEC VAX guys. Over the years it has shed a lot of Microkernel attributes and become more of a macro style kernel.
Mach is a fairly standard, well documented design principal.
Microkernels are a fairly standard, well documented, design principal. Mach is an instance of them.
I actually agree with some of your other statements, your parent poster was an uninformed fanboy. Apple has contributed to BSD though, check out the BSD project list and see where.
Remember? I'm still dealing with it... Oi!