The Sorenson codec may not be owned by Apple, but they are the sole licensees from Sorenson, and Sorenson cannot release the codec to anybody else without Apple's approval.
So, if you contact Apple, they will say "Don't talk to us, we don't own it, talk to Sorenson."
And if you talk to Sorenson, they will say "We'd LOVE to license it to you, really we would, but we cannot without Apple's approval, go talk to them".
I have the story archived at home. I'm on vacation at the moment, but I can send you what I have. Several people here on/. have asked for somebody to put it up.
If you wish, reply and we can move it over next week.
Preface: I've been an embedded systems software engineer since 1987. I've been programming in C for almost all of that time, and C++ since '91. I've designed systems with over 250kloc, hard realtime.
The biggest single advantage of OOD is that you can say "This sort of thing will have a function that does something like this, but I won't make the final decision on exactly HOW to implement that function until late, when I have more information on what needs to happen."
Let me give you a concrete example. I had to design the code to reprogram the flash in one of our devices. I faced the following problems:
1) the way the data got to us could either be Xmodem or Ymodem.
2) The file format could be either OMF or raw binary.
3) The types of memory devices could change - they could be Intel type 1 flash, AMD type 1 flash, or Intel type 2 flash (or RAM), all of which have different programming requirements.
3a) In addition, the types of flash could be changed by the production line (based on what was available - most of those parts were "on allocation", meaning "you take the quantities we give you and you like it - you ain't IBM so you don't matter".
3b) The types of flash on a given unit could be mixed - you had to probe at runtime to figure out what you had.
So, here's how I decomposed it:
1) I had two file type objects: OMF and Binary. They each HAD-A Input object, which provided data , and HAD-A Memory object, which would program memory. The OMF object read OMF records from the Input object, parsed the OMF records, extracted the data, and commanded the Memory object to program regions of memory.
2) I had an Xmodem object, which WAS-A Input object. It read data from the serial port, handled the checksum or CRC verification, block counting, and made the data available to the user (the file object).
3) The Memory object HAD-A pointer to a Memory_driver object. When the Memory object was commanded to write to a block of memory, it verified that the write was in the current block, and if so passed the request to the Memory_driver object. If not, the Memory object HAD-A list of Memory_driver_list objects, which each HAD-A pointer to a function that would probe a given memory address and return either NULL or a pointer to a newly created Memory_driver object. The Memory object would iterate through the list, asking each Memory_driver_list object "Can you program this?". When one of them returned a non-null value, the Memory object would delete the old Memory_driver, and use the new Memory_driver.
4) I had Intel_series1, Intel_series2, AMD_series1 and RAM objects, all of which WERE-A Memory_driver. Each class HAD-A static instance of a Memory_driver_list object, which automatically linked itself to the driver list. Each driver HAD-A static member function to probe memory and return a pointer to a newly created driver if needed.
First, this let each routine be focused on what it needed to do - the Xmodem routines didn't worry about OMF format, the OMF didn't do Xmodem handshakeing, the Memory routine didn't care about the specifics of programming memory. I could test each object out in isolation, get it working, and move on. Now, you can do this with proceedural programming techniques too.
Second, when a new type of memory was added, I was able to just write the driver for it, and not touch the OMF object, the Memory object or the file transfer objects. They automatically picked up the new driver. Now, you can do this in a proceedural language like C, but how do you do so? You make each driver have a table of function pointers, and you have the upper level code keep track of a void * that contains your driver information. Guess what - that's OOP! The function table is the same as a C++ vtable, the void * is your this pointer. Except that in C, you have to track all that stuff yourself, in C++ you can let the compiler worry about the BS and you focus on the code design.
In short, OOD helps, but you still have to use it correctly.
Actually, those stations get a hell of a lot more than just "air, snow, gravity" - they get massive shipments of fuel oil, food, construction materials, electronic supplies, medical supplies, you name it.
They manufacture almost NONE of their needs.
Now, were we to build a south pole station that actually DID use only water, air, and gravity, and created everything else they needed from materials found at the south pole and processed there, that would be something.
So sad to have to explain the joke, but some people don't seem to get it....
"rooting" is slang for "attempting to access a computer illegally and gain administration access to it".
Thus, when using the term "rooting" with respect to a network supplier, it is a poor choice of terms.
A better one would have been "pullling", since another possible meaning of that would be "pulling networking cable or fiber", which is far more apropos to a network supplier...
True, once somebody has a shell prompt, they can use any local exploit to become root. However, unless login is SUID root, this gives them no additional priviledges.
This is a bad vulnerability, but not awful - you have to be allowing Telnet or RLogin access to the server for this exploit to be at risk.
Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties. You should never deploy them where bad guys can get ahold of them - in those cases you should use (open)SSH.
It takes a fair bit of time for a fuel cell to start making power after you start the fuel feed. The batteries are there to a) allow the unit time to come up and b) to allow the unit to respond to surges like your monitor coming up.
First, let me say that line was the most buzzword-complient I've ever seen.
Second, how can it be both "platform-agnostic" and yet only show up on IE? It just goes to show that the buzzword list was created in the complete absence of information on the product.
Third, let me say that I am glad this is IE only, as it won't affect my browsing under Mozilla.
Fourth, what is it with marketing people - do they STUDY to learn how to alienate their customers, or to they just come into it naturatlly?
I work for a company that has offices in both the US and England. I get about 50 spams/day on my work mail account. I wonder if I could get our IT department to move our mail server to the other side of the pond, and would that provide legal leverage to nuke these offspring-of-unmarried-syphillic-camels?
Another possible competitor
on
Why ADCo?
·
· Score: 2
The biggest single problem in the last mile is cost of driving a cable of any sort to your house. You have to have right of way access to the property, you have to dig a trench, you have to have junction points. The cost of the cable itself it trivial.
Right now, we have the cable companies and the telcos driving cables to your house, since they are already going that way. But there is a third possible player that hasn't yet entered the fray.
I used to live in the city, and had my electric bill on direct debit. I now live in the country, and belong to an electrical co-op. To keep the price down, they don't have routine meter readers - I have to read my own meter and report usage (and the occasionally spot-check me). As a result, direct debit is out - I cut them a check ever month.
Last month, as I was hiking out to the meter, I thought, "The electric company already has a right of way to the meter, why don't they drop a cable alongside the power line and set up a smart meter. Then, they could also offer data services, as well as variable rate metering (different costs per KWH based on time of day)".
Think about it.
1) Look at Qwest - they used to be a GAS PIPELINE company. They needed data on the pumping stations, so they ran fiber. Their CEO had vision - he made them run a lot of extra fiber.
2) Like a telco (and quite UNLIKE a cable company) the electric company understands uptime. If your cable goes down, "we'll fix it in a few days" is considered acceptable. If your phone or power goes down, a truck is rolling in minutes after the report, rain, shine, or hurricane.
3) The power companies would LOVE to be able to encourage people to spread the load to off-peak times, but they have no good way of offering the average consumer a reward for doing so. Variable rate billing would solve that problem.
4) If they had a network to read the meters, they could save money on meter readers.
I think the only reason this has not happened yet is that power company CEOs don't have the vision Qwest had.
I checked out the Dragon Spirit site just to see what it was. The main page told me nothing of what the intended audience was. I had to go to the about link to see who they were targeting (and determine that it was of no interest to me).
Compare and contrast that to/.: Right there on the main page is "Slashdot: News for Nerds. Stuff that Matters." Right off, I can get a pretty good idea of whom/. is targeting, and make a decision as to whether I stick around or leave.
On the web, you have about 10 seconds to grab my attention - then I'm outta here. Too many web sites overlook this rule - 50 second downloads of flash, useless intro pages, a failure to state what their target interest is, excluding anybody who isn't running $browser at $x_resolution by $y_resolution with @plugins.
It's just like real life (in fact, most things online are "just like real life") - if you want to build a group, you cannot needlessly exclude anybody. I belong to two amateur radio clubs - one welcomes anybody to its meetings, licensed or not. The other has two old farts who dump on anybody who didn't work with Marconi (not the company, the man!) and are abusive to everybody else. Guess which club is healthy, and which is dying!
Be easy to join, be clear who you are targeting, stomp on the trolls who drive off new members, don't be too overly narrow in your focus, and you might be able to create a group.
A thermal diode IS a Peltier element. This has been covered in EE Times among other trade journals. All they've done is take the standard BiTe diode, which is very thick, and thinned it down by creating the layers with standard chipmaking techniques. So, instead of one diode junction being about 1mm thick, they make a device that is 0.1mm thick consisting of many tens of layers.
Unfortunately, unless you are familiar with the Debian distro and know that "boot-floppies" is more of a proper noun than a simple designation, the comment is misleading.
Somewhat similar to saying "I finally got my woodie up" in the general public.
Installers that work by using a boot floppy to access a network image of the install are still one of the best ways to install systems in a large environment:
1) You don't have to configure the machine to boot from CD, then remember to turn that back off in the BIOS when you are done.
2) HTTP or NFS access across a 10Base-T is about equal to a 10 spin CD-ROM - across a 100Base-t its faster than all but the most top of the line DVDROM drives.
3) Start one install, as soon as the machine boots remove floppy, insert into next machine, and repeat.
Don't get me wrong - I like CD installs for single machine environments. But I ALWAYS have the latest copy of RedHat exported from my server in the basement - makes it a lot easier when rolling a firewall/scratch machine/whatever.
If you don't want to be troubled to write a physical letter (and don't want your dandruff to be mistaken for anthrax) then go to Western Union's site and telegraph your congressdrone. Telegraphs get read since they cost money.
Bury them in Western Union messages and they will perk up!
And I was talking about the way most folks buy their games - they walk into a store and walk out with the game.
On the contrary, I saw several stores (I'd estimate 50% of the ones I checked out) that carried Q3 Linux. However, not all of these stores stocked them in with the "regular" video games... sometimes you'd have to look for the shelf that displayed Linux distributions and software and you'd see the Q3 among them. I don't mean backwater ma & pa stores, I'm talking about Software Etc, Electronics Boutique, Babbages, et al.
What part of "live in a large city with a computer specialty store" wasn't clear to you?
I'd be very wary of drawing any conclusions from the results of Quake 3:
Id released the Linux version of Q3A several weeks after the Windows version. If you are a die-hard gamer, you probably have dual-boot capability. Which would you do - wait three weeks for the new hot game, or buy the Windows version immediately and then download the Linux binaries when the become available?
The Linux version only sold in the premium metal tin box, for US$50. The Windows version sold in the cardboard box for US$30. Again, which route are you most likely to take?
At the time Q3A was released, the Direct Rendering Infrastructure was just barely coming up to speed. Most cards weren't well supported. That has since changed (some)
Finding a retail store that stocked the Linux version was difficult. If you didn't live in a large city with a computer specialty store, you had no option - you were going to buy the Windows version.
Ideally, Id should have simply released 1 package with both the Windows and LinuxX86 versions on it, and relied upon the registration process to identify who ran what.
This is just unbelievable. The whole idea of NAT is to hide the actual number of IP addresses behind the NAT box. There is no way the cable company can detect that I am running NAT from their side of things - the most they might be able to do is require me to run a program on my PC that they can talk to in order to interrogate what my PC thinks its IP address is. And since I don't run Windows, I wouldn't be their customer.
It's all about bandwidth - if you sell me 10MB/sec and you don't put any other limits on it, then more fool you! If you throttle me, either by limiting my peak bandwidth or by limiting my max transfers per month, then you don't care how many devices I have behind the firewall.
Gods and Daemons, am I glad I have a sensible ISP that doesn't care what I do with my 384Kb/sec.
Slashdot Mirror
The Sorenson codec may not be owned by Apple, but they are the sole licensees from Sorenson, and Sorenson cannot release the codec to anybody else without Apple's approval.
So, if you contact Apple, they will say "Don't talk to us, we don't own it, talk to Sorenson."
And if you talk to Sorenson, they will say "We'd LOVE to license it to you, really we would, but we cannot without Apple's approval, go talk to them".
Nice game of "Go ask your mother" there...
I have the story archived at home. I'm on vacation at the moment, but I can send you what I have. Several people here on /. have asked for somebody to put it up.
If you wish, reply and we can move it over next week.
Preface: I've been an embedded systems software engineer since 1987. I've been programming in C for almost all of that time, and C++ since '91. I've designed systems with over 250kloc, hard realtime.
The biggest single advantage of OOD is that you can say "This sort of thing will have a function that does something like this, but I won't make the final decision on exactly HOW to implement that function until late, when I have more information on what needs to happen."
Let me give you a concrete example. I had to design the code to reprogram the flash in one of our devices. I faced the following problems:
1) the way the data got to us could either be Xmodem or Ymodem.
2) The file format could be either OMF or raw binary.
3) The types of memory devices could change - they could be Intel type 1 flash, AMD type 1 flash, or Intel type 2 flash (or RAM), all of which have different programming requirements.
3a) In addition, the types of flash could be changed by the production line (based on what was available - most of those parts were "on allocation", meaning "you take the quantities we give you and you like it - you ain't IBM so you don't matter".
3b) The types of flash on a given unit could be mixed - you had to probe at runtime to figure out what you had.
So, here's how I decomposed it:
1) I had two file type objects: OMF and Binary. They each HAD-A Input object, which provided data , and HAD-A Memory object, which would program memory. The OMF object read OMF records from the Input object, parsed the OMF records, extracted the data, and commanded the Memory object to program regions of memory.
2) I had an Xmodem object, which WAS-A Input object. It read data from the serial port, handled the checksum or CRC verification, block counting, and made the data available to the user (the file object).
3) The Memory object HAD-A pointer to a Memory_driver object. When the Memory object was commanded to write to a block of memory, it verified that the write was in the current block, and if so passed the request to the Memory_driver object. If not, the Memory object HAD-A list of Memory_driver_list objects, which each HAD-A pointer to a function that would probe a given memory address and return either NULL or a pointer to a newly created Memory_driver object. The Memory object would iterate through the list, asking each Memory_driver_list object "Can you program this?". When one of them returned a non-null value, the Memory object would delete the old Memory_driver, and use the new Memory_driver.
4) I had Intel_series1, Intel_series2, AMD_series1 and RAM objects, all of which WERE-A Memory_driver. Each class HAD-A static instance of a Memory_driver_list object, which automatically linked itself to the driver list. Each driver HAD-A static member function to probe memory and return a pointer to a newly created driver if needed.
First, this let each routine be focused on what it needed to do - the Xmodem routines didn't worry about OMF format, the OMF didn't do Xmodem handshakeing, the Memory routine didn't care about the specifics of programming memory. I could test each object out in isolation, get it working, and move on. Now, you can do this with proceedural programming techniques too.
Second, when a new type of memory was added, I was able to just write the driver for it, and not touch the OMF object, the Memory object or the file transfer objects. They automatically picked up the new driver. Now, you can do this in a proceedural language like C, but how do you do so? You make each driver have a table of function pointers, and you have the upper level code keep track of a void * that contains your driver information. Guess what - that's OOP! The function table is the same as a C++ vtable, the void * is your this pointer. Except that in C, you have to track all that stuff yourself, in C++ you can let the compiler worry about the BS and you focus on the code design.
In short, OOD helps, but you still have to use it correctly.
Speaking of Menudo, have you ever considered putting the old "story of Propaganda" back up?
Why would I celebrate Perl's birthday. All she does is send horrible movies to those nice 'bots....
Oh, wrong Perl. Nevermind..
I'll send them cheesy movies
The worst I can find <la-la-la>
They'll have to sit and watch them all
And I'll monitor their minds <la-la-la>
Actually, those stations get a hell of a lot more than just "air, snow, gravity" - they get massive shipments of fuel oil, food, construction materials, electronic supplies, medical supplies, you name it.
They manufacture almost NONE of their needs.
Now, were we to build a south pole station that actually DID use only water, air, and gravity, and created everything else they needed from materials found at the south pole and processed there, that would be something.
So sad to have to explain the joke, but some people don't seem to get it....
"rooting" is slang for "attempting to access a computer illegally and gain administration access to it".
Thus, when using the term "rooting" with respect to a network supplier, it is a poor choice of terms.
A better one would have been "pullling", since another possible meaning of that would be "pulling networking cable or fiber", which is far more apropos to a network supplier...
Ahh, so Covad is where all the 5|r!97 \!dd!3z are hanging out...
Poor choice of phrase...
True, once somebody has a shell prompt, they can use any local exploit to become root. However, unless login is SUID root, this gives them no additional priviledges.
This is a bad vulnerability, but not awful - you have to be allowing Telnet or RLogin access to the server for this exploit to be at risk.
Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties. You should never deploy them where bad guys can get ahold of them - in those cases you should use (open)SSH.
It takes a fair bit of time for a fuel cell to start making power after you start the fuel feed. The batteries are there to a) allow the unit time to come up and b) to allow the unit to respond to surges like your monitor coming up.
First, let me say that line was the most buzzword-complient I've ever seen.
Second, how can it be both "platform-agnostic" and yet only show up on IE? It just goes to show that the buzzword list was created in the complete absence of information on the product.
Third, let me say that I am glad this is IE only, as it won't affect my browsing under Mozilla.
Fourth, what is it with marketing people - do they STUDY to learn how to alienate their customers, or to they just come into it naturatlly?
I work for a company that has offices in both the US and England. I get about 50 spams/day on my work mail account. I wonder if I could get our IT department to move our mail server to the other side of the pond, and would that provide legal leverage to nuke these offspring-of-unmarried-syphillic-camels?
The biggest single problem in the last mile is cost of driving a cable of any sort to your house. You have to have right of way access to the property, you have to dig a trench, you have to have junction points. The cost of the cable itself it trivial.
Right now, we have the cable companies and the telcos driving cables to your house, since they are already going that way. But there is a third possible player that hasn't yet entered the fray.
I used to live in the city, and had my electric bill on direct debit. I now live in the country, and belong to an electrical co-op. To keep the price down, they don't have routine meter readers - I have to read my own meter and report usage (and the occasionally spot-check me). As a result, direct debit is out - I cut them a check ever month.
Last month, as I was hiking out to the meter, I thought, "The electric company already has a right of way to the meter, why don't they drop a cable alongside the power line and set up a smart meter. Then, they could also offer data services, as well as variable rate metering (different costs per KWH based on time of day)".
Think about it.
1) Look at Qwest - they used to be a GAS PIPELINE company. They needed data on the pumping stations, so they ran fiber. Their CEO had vision - he made them run a lot of extra fiber.
2) Like a telco (and quite UNLIKE a cable company) the electric company understands uptime. If your cable goes down, "we'll fix it in a few days" is considered acceptable. If your phone or power goes down, a truck is rolling in minutes after the report, rain, shine, or hurricane.
3) The power companies would LOVE to be able to encourage people to spread the load to off-peak times, but they have no good way of offering the average consumer a reward for doing so. Variable rate billing would solve that problem.
4) If they had a network to read the meters, they could save money on meter readers.
I think the only reason this has not happened yet is that power company CEOs don't have the vision Qwest had.
I'd rather they did a miniseries of DOON - the Dessert planet"
A much more entertaining read....
And he shall pour a beer without head, and it shall be nothing
I checked out the Dragon Spirit site just to see what it was. The main page told me nothing of what the intended audience was. I had to go to the about link to see who they were targeting (and determine that it was of no interest to me).
/.: Right there on the main page is "Slashdot: News for Nerds. Stuff that Matters." Right off, I can get a pretty good idea of whom /. is targeting, and make a decision as to whether I stick around or leave.
Compare and contrast that to
On the web, you have about 10 seconds to grab my attention - then I'm outta here. Too many web sites overlook this rule - 50 second downloads of flash, useless intro pages, a failure to state what their target interest is, excluding anybody who isn't running $browser at $x_resolution by $y_resolution with @plugins.
It's just like real life (in fact, most things online are "just like real life") - if you want to build a group, you cannot needlessly exclude anybody. I belong to two amateur radio clubs - one welcomes anybody to its meetings, licensed or not. The other has two old farts who dump on anybody who didn't work with Marconi (not the company, the man!) and are abusive to everybody else. Guess which club is healthy, and which is dying!
Be easy to join, be clear who you are targeting, stomp on the trolls who drive off new members, don't be too overly narrow in your focus, and you might be able to create a group.
A thermal diode IS a Peltier element. This has been covered in EE Times among other trade journals. All they've done is take the standard BiTe diode, which is very thick, and thinned it down by creating the layers with standard chipmaking techniques. So, instead of one diode junction being about 1mm thick, they make a device that is 0.1mm thick consisting of many tens of layers.
Unfortunately, unless you are familiar with the Debian distro and know that "boot-floppies" is more of a proper noun than a simple designation, the comment is misleading.
Somewhat similar to saying "I finally got my woodie up" in the general public.
Installers that work by using a boot floppy to access a network image of the install are still one of the best ways to install systems in a large environment:
1) You don't have to configure the machine to boot from CD, then remember to turn that back off in the BIOS when you are done.
2) HTTP or NFS access across a 10Base-T is about equal to a 10 spin CD-ROM - across a 100Base-t its faster than all but the most top of the line DVDROM drives.
3) Start one install, as soon as the machine boots remove floppy, insert into next machine, and repeat.
Don't get me wrong - I like CD installs for single machine environments. But I ALWAYS have the latest copy of RedHat exported from my server in the basement - makes it a lot easier when rolling a firewall/scratch machine/whatever.
I do hope Wil will keep us posted. Will you, Wil?
If you don't want to be troubled to write a physical letter (and don't want your dandruff to be mistaken for anthrax) then go to Western Union's site and telegraph your congressdrone. Telegraphs get read since they cost money.
Bury them in Western Union messages and they will perk up!
I wanted to get Bruce's reaction to Wil's question! Dammit, call him back and ask it!
And I was talking about the way most folks buy their games - they walk into a store and walk out with the game.
What part of "live in a large city with a computer specialty store" wasn't clear to you?
Ideally, Id should have simply released 1 package with both the Windows and LinuxX86 versions on it, and relied upon the registration process to identify who ran what.
This is just unbelievable. The whole idea of NAT is to hide the actual number of IP addresses behind the NAT box. There is no way the cable company can detect that I am running NAT from their side of things - the most they might be able to do is require me to run a program on my PC that they can talk to in order to interrogate what my PC thinks its IP address is. And since I don't run Windows, I wouldn't be their customer.
It's all about bandwidth - if you sell me 10MB/sec and you don't put any other limits on it, then more fool you! If you throttle me, either by limiting my peak bandwidth or by limiting my max transfers per month, then you don't care how many devices I have behind the firewall.
Gods and Daemons, am I glad I have a sensible ISP that doesn't care what I do with my 384Kb/sec.