FYI, if you are capable of performing this particular hack, it's a matter of about 10 seconds to restore it to functionality with OnStar.
The hack itself involves the following steps: 1) Solder a serial cable onto the GPS unit. 2) Hookup a laptop 3) Send a command that sticks the GPS unit into a different mode (NMEA) which is standard and works with all the mapping software you could want.
Getting it back to working with OnStar involves: 1) Sending a command to it to stick it back into Motorola binary mode 2) Unplug the laptop
You can leave the serial interface there. It doesn't mess with anything. And OnStar will work just fine once the GPS box is back in the mode that OnStar expects it to be in.
So your resale value isn't really an issue here. Admittedly, you can ruin the thing if you screw up the soldering, but the soldering part on this one isn't particularly difficult to do.
OnStar doesn't track the cars continuously. Anyone with half a brain could deduce that from the evidence.
a) It has an analog cell phone b) All communication goes through the cell network c) Using the cell network costs $$$
The way it works is that when you press the OnStar button, the cell phone calls home and connects you with a rep. The GPS data is transmitted at that time in case you want directions or something.
It also calls home in the event of an airbag deployment. (In the case of newer model GM cars, this connection between the car's class 2 network and the OnStar box is actually through the radio's wiring and so it may not work if you put in a third party radio without using the proper wiring harness, which bypasses the radio connection.)
While it's true that OnStar can call your box directly (such as if you want to unlock your doors or in the event that your vehicle is stolen and they want to track/disable the car), there's no real benefit for them to know your location at all times. How is them knowing where you are helping them financially to the extent that they would pay money for the call to your car to gather that data? It's not like the data can magically appear on their system without some form of transmission from your car to them. They have to contact your car and get that data, and that means the cellular networks will want cash for them to do that. So that data would have to be more valuable to them than the cost of the calls to the car.
This is likely because VW's are shit. If it's that easy to fry their diagnostic equipment, then why in the hell don't they put an opto-isolator inline with the diagnostic box's connection and prevent all electrical surges from making it to the diag box? Because they are idiots, that's why.
The radio and OnStar and such is tied together in GM vehicles too, using what is known as a class 2 network. Basically, there's a single wire running to every module in the car, including the radio and the OnStar box (and even the CD Changer if you have a factory one). They all communicate with each other using the J1850 VPW protocol. Yes, I suppose that if you ran some large amount of voltage on that wire, you could conceivably fry the modules, but then the car wouldn't work anymore in a fairly obvious way and so you really wouldn't have a hard time figuring out the problem. Certainly the computer wouldn't figure it out by hooking it up, since there's nothing for it to talk to in the car anymore.
Anyway, this guys mod is pretty basic and doesn't involve tinkering with the "brain" of the OnStar box in any way. All he did was to solder a serial connection onto the GPS board and then disconnect that board from the OnStar system. The GPS doesn't talk to the rest of the car directly, it goes through the brain unit. So nothing this guy does to the GPS can really affect the rest of the vehicle. It's not connected to the rest of the vehicle after he's done with it. Except insofar as it's drawing power from the vehicle.
As always, if you don't know what you're doing, you shouldn't mess with your car's electronics. But if you're inclined to tinker with your car, and you are capable of understanding electronics, it's not really difficult to figure out how this stuff works. This isn't brain surgery here, anyone with rudimentary electronics skills can work it out and get stuff to work correctly. If it was all that complicated, mechanics wouldn't be able to do it (no insult to mechanics intended, they simply have more of a mechanical viewpoint instead of an electronic viewpoint in very general terms).
This is definitely FUD on the part of GM. The Magnusson-Moss Act of 1975 specifically addresses this. Mainly, while modifying your OnStar system may void the warrenty on the OnStar box, they need to be able to *prove* that your modification was the actual cause of whatever is wrong with the car before they can claim that it's not covered under the warrenty.
This isn't all that new. All that it is really doing is building a serial interface onto the GPS part of the OnStar module and letting you access the data directly. Why bother?
1) The data is there already. It's cool to have access to it.
2) Many people, myself included, find OnStar somewhat useless, and don't pay for a subscription after the first free year. So it's nice to get some use out of that hardware that was already in the purchased vehicle anyway.
3) Using the built in GPS unit means no visible GPS antenna or hardware or what have you.
4) Because you can.
There's other parts of the OnStar hardware that are kinda cool too. The thing is basically a brain unit hooked to an analog cell phone and a GPS receiver. There's a built in microphone (in my case in the rear view mirror) and a connection to the car stereo system (both for audio and data, data being to display information on the radio display). Mainly I've been trying to hack the thing to let me use my own cell phone with the unit and thus make hands free calls, using the brain unit for the voice dialing functionality and so forth. Thus letting me make calls on my own phone without pahying the buck a minute charged by OnStar for their phone service.
Hey, the box in the car is *mine*. I paid for it, and I can do as I please with it.
Urm... would you let someone else dial into your network? I wouldn't let you into mine. You're not a library and I'm not a local LUG offering you free hardware and software in order to benefit your customers.
But it's the GPL, not Copyright Act that states the proprietary code needs to be released as GPLed open code. Why couldn't a judge order them to do that? It's not unthinkable.
Actually, it is, because the infringer still has a choice. Either they can agree to the GPL, in which case they have to GPL the derived code, or they can disagree with it, in which case they have to remove the GPL'd code entirely. The judge cannot force someone to agree to the license, the most he can do is force them to stop infringing by using the copyrighted code.
The suit the GPL'd code's author brings will be a copyright violation suit, because that's exactly what the infringer will have done. Used copyrighted code without permission. There's no contract for the GPL'd code's author to enforce. He hasn't gotten their agreement to the GPL. They can always agree to it or disagree to it, as they choose. It's just that whether they are infringing his copyright or not hinges on their agreement or disagreement.
This is a good idea. Especially if the library has broadband internet access (as many do nowadays). The local LUG could then administer the box by providing updated images to it remotely.
I figure that with just a bit of effort, you could make a small tabletop version of this for under $1000 or so. I mean, all it needs is a cheap system, a burner (preferably without a tray, as they tend to get broken in public places), and a monitor. Form factor could be exceedingly thin with a custom casing for it, esp. if you used an LCD panel for the screen.
Thin and small is good here, because that means it's not taking up space in the library, which would make getting the librarians to agree much easier.
Write some custom software to basically provide a menu of images that the user can pick from (and optionally allow the local LUG to remotely administer the thing), assure the librarian that it's all open source software (which entails explaining OSS to them), get their agreement and assure them that it's no maintainance at all for them (plus let them sell blank CD's/DVD's on a markup, and it'd be done.
Actually, let me rephrase part of that.. The purpose of the diplexer is to block the DC current from the receiver from hitting your TV tuner. Most diplexers don't block the frequencies from hitting the tuner (although they can, I guess), they just block the DC power, because that definitely would be bad for the TV tuner. If it wasn't for that DC power signal, you could use a normal splitter and it would work just fine, most likely.
Do you know of any other these multiswitches that DOESN'T require a diplexer at the output end to split the antenna/cable from the satelite. I was thinking of using one of these ( and I would be only using the satelite inputs; no cable/antenna ), but that drawback is a major PITA.
You don't need a diplexer at the receiver end unless you want to get that antenna signal off the wire. You can feed the combined sat+antenna signal into a receiver with no ill effects whatsoever. The sat receiver isn't tuning the low band antenna stuff, and so it's irrelevant to the receiver. The reason for the diplexer is to a) split the cable and b) block the high frequency satellite stuff from hitting your television, because it could be bad for the TV tuner. The satellite's tuner doesn't care.
And if you have no antenna hooked up to the switch, it's irrelevant anyway.
I dunno about an office setting, but as a developer, I use Access whenever I'm prototyping a new database. It's easy to create a new database, easy to access through Jet, and easy to modify on the fly when I screw it up. It lets me work out my table structures and run test queries using my programs or directly via the SQL. Okay, I have to work around its fucked up SQL if I work with Access directly, but the Jet engine's SQL seems to be mostly standard and works much differently from Access's SQL builder crap.
Anyway, once I've determined how I want it to work, then I can build the same structure using a real DB, like mySQL or Oracle or whatever. Converting my code to then use the new database is fairly quick and easy.
Access is fine for prototyping and testing, but I'd never use it in any real situation. Maybe if I was making a simple shareware program and needed a database that would work on most all Windows boxes, but that's about it.
We've also used Access in small intranet web applications, where the data isn't all that critical and we just need an easy way to access and display it to the members of the team, and the capability to easily modify it as needed. It's quick to develop for and works well enough in small-scale stuff. Sure, the time could be put in to make a real system, and it would have a lot of advantages if we used a real database, but we're talking throwaway code here, developed quickly to accomplish a goal that won't be around all that long, sort of thing.
I dunno.. if the efficiency per photon remains constant the temperature shouldnt increase. "in theory" you should be absorbing and emitting the same number of photons per second as a normal window would.
Yes, but only once light had passed through the thing. I mean, let's say you create a pane of glass that takes a year for light to pass through. For the first year, it's going to be as black as black can be, because it hasn't had time for the light to pass through it. Temp will increase all for that year. It would reach maximum once it started emitting, I grant you.
Interesting story, I grant you, but if such a thing existed, you'd have to wonder at the temperature the glass would reach after absorbing light for a few years. It'd be possible to do something similar to it using other methods, but I doubt the possibility of doing it using anything similar to the methods described in the book.
I think you read too much into my statement, but you're not alone there, so I don't fault you for it. I didn't mean anything along the lines of "hackers will destroy Tivo!" or anything similiarly stupid like that.
What I meant was simple, although badly expressed.
Tivo's latest offerings are oriented more towards technical things. HMO has things like web access to your box, MP3 and photo viewing, network and internet dialing, show sharing over a network, etc.. All off this stuff isn't what non-techie moms and pops are going to be doing, but it is an attempt by Tivo to get income. If Tivo hackers don't see a reason to "back off", then they could duplicate this sort of functionality on Tivo boxes for, essentially, free, and thus undermine Tivo's latest attempt, and perhaps any future attempts, at generating income.
Now I'm not saying anyone would do this intentionally, but in the past, Tivo's semi-hacker-friendly attitude has been just about the only thing stopping people from directly messing with anything related to Tivo's income. It's why people didn't mess with the service. It's why nobody has directly gone and done something more damaging to the advertising. It's why the information on how to clone serials and thus steal service properly isn't all that widely distributed. It's why the Tivo dialup service emulator programs are mostly limited to Canadian users, despite the fact that it could essentially replace the service functionality for every box out there and totally undercut Tivo's revenue. It's why nobody has really seriously tried to enable HMO without paying the $99 fee (and that one isn't even all that difficult to do, really).
There's a lot of ways that hackers could hurt Tivo by accident or by design, and hackers have generally taken the stance of limiting or not releasing things that could be potentially damaging. They liked the company, they liked the hardware, they granted that Tivo should make cash off it since it's a cool box and a cool company.
If that attitude changes, then some people may not restrict themselves so much in releasing software that has the *potential* to undercut Tivo's income stream. With, for example, a service emulator, I could run the emulator on my box. The Tivo would "dial in" to my own machine, get its guide data from there (which could be culled from online sources, which are free), and thus I'd have full functionality without paying Tivo one thin dime. Such software exists, but is limited in scope and distribution because hackers like Tivo. And that's because Tivo hasn't tried to stop hackers. They've generally said "hey guys, knock yourself out, but there's limits, okay?" in the past, and if that changed, well, it wouldn't be a good thing for anybody, would it?
Then the source code, as defined by the GNU General Public License, is not complete. The GPL defines the "complete source code" of an executable work as "all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." If compilation and installation of the executable includes a digital signature, then it could be argued that the scripts would have to include the private key used to sign the executables.
It's a fine point, actually. You are more than welcome to compile a Tivo kernel and run it on your own hardware. But newer Tivo hardware requires a kernel signed by Tivo (the BIOS checks the signature on the kernel before it will boot it). Tivo's hardware is the one enforcing the signature check here, and they don't have any obligation, under the GPL, to provide the ability to sign code to run on their hardware. So they have fulfilled the GPL to the extent that you can compile and use the code on any normal hardware, but their hardware is special.
It's a bit of a tricky point, methinks. None of their *code* is checking the signature. Their hardware is. The Tivo kernel you compile will run just fine, on any hardware you happen to get it to run on. You can install it on any hardware you have all day long. But it's debatable as to whether they have to provide you with the capability to run it on their proprietary box though.
Boy, you sure can read between the lines.. Badly, I might add.
business model is based on extorting a monthly fee for a VCR
With the standalones, it's not all that unexpected.. The unit needs continuing guide data, Tivo provides that data. Value received for payment made. With the D-Tivo's you have a point, but the fee on the D-Tivo's is so low that it's not even worth thinking about it.
acting like a jackbooted thug and violating the GPL
Tivo isn't violating the GPL, in even the most restrictive sense you can possibly put the GPL. They're totally in the clear on this one.
you're saying that you're surprised
I'm surprised in that I'm not sure what this particular action gets them in terms of a gain. It's one thing if this was costing them subscriptions or sales, but it's not, as far as I can see. So I fail to understand why they took this course, because it gains them nothing of import.
DirecTivos don't do their software updates over the phone, they get them from the satellite, then dialup to verify that the machine is active, then run the patches. I can't be 100% sure, but the standalones and the DirecTivos are completely different, so there's no way to just magically make HMO (Home Media Options) work.
Not yet they don't.
DirecTivo's still get their software updates over the phone line. The capability exists to do software patching via the satellite, but to my knowledge (admittedly limited on this point), they have not used it yet.
And the "magic" way to make HMO work on Series 2 D-Tivo's is indeed to copy a Series 2 standalone image with activated HMO to the unit. This was discovered a few months ago. Tivo unified their code base with the series 2 systems a while back, and one side effect of this was that the code became unified enough to where the standalone image was in fact "close enough" to work more or less correctly on a D-Tivo. Doing this and letting it then dial in would be an exceedingly stupid thing to do, but no doubt some morons did it anyway.
This highlights a bit of a problem with Tivo's latest offerings, one that I bitched about on the Tivo Community forums back when I was still welcome there. They are charging, on a monthly basis, for what is essentially a one time software update. Every feature of the HMO (Home Media Option) stuff, with the exception of web access to your Tivo, is done by the unit itself and requires no external connection as such. The MP3 playing, show sharing, picture viewing, all of that doesn't need the unit to call home to be able to do any of it. So it was really only a matter of time before someone flipped their own switches on the box, I argued. The unification of the code base between D-Tivo's and Standalones let people figure out how to flip their own switches on the D-Tivo's as well. Take an HMO activated standalone, copy it to the D-Tivo, voila.
Tivo is headed down the drain, IMO. They made a very good product, and changed the landscape of TV viewing. But they've made some very poor decisions with regards to their business strategies and software designs, and now it's starting to bite them in the ass.
I'm starting to feel like it's only a matter of time before it's full on war between Tivo hackers and Tivo Inc., and Tivo Inc. doesn't stand a chance on this one. The majority of Tivo sales have classically been via word of mouth, and if they don't turn it around, they're going to alienate their best and most vocal sellers, ya know?
I haven't seen TiVo's userland code, but I expect it's tightly tied to their own libs and module code.
You'd probably be wrong there. I haven't seen the actual userland code either, but I have messed about on the Tivo extensively, and it's not "tightly" tied by any means. They do have modules for the hardware which they have released, I think, but these provide more or less normal interfaces to it for the most part, and there's little need to compile their headers and such into the userland code and so forth. The kernel modules mostly just provide/dev device interfaces which any program can use, type of thing. It's a pretty good layer of separation, in other words.
But if they've added drivers for TiVo specific hardware (don't know if there is any, don't have a TiVo) then it's down to the old binary modules argument, and if they've modified the kernel in any way then they need to release those modifications.
There is and they have. http://www.tivo.com/linux
The objection to distribution of images is that image necessarily contain their proprietary userland code, which is decidely not GPL.
I suspect their concern is that someone will figure out how to hack their way into their servers Already done, but easily detected on their end, more or less.
or steal DirecTV service Also already done, and not easily detectable either. But it's no easier than stealing DTV on any other DTV box.
or eventually manage to run the whole image on "stock" hardware. Not bloody likely, and considering that this particular site has been in operation *at least* three years to my explicit knowledge, nobody is really interested.
I know a lot about Tivo and the hacking community and such, and I'm at a loss to satisfactorily explain why Tivo would do this. I suspect a Tivo lawyer found out about it. Most of the Tivo engineering people have no real issue with this sort of thing.
Tivo is well within their rights here, but to my absolute and certain knowledge, several key people at Tivo have known about ftp.abs.net for at least 2 years. I'm just not sure why this is happening now.
That's more or less exactly how these images were made. Early on, images were made using dd. Nowadays, people make images using a special program called "mfstool" which is capable of backing only the necessary parts of the Tivo drive, reducing the size of the created image. So all the sites recommend making your *own* image. But sites like abs.net existed as a just in case type of mechanism. If your system failed, and you never made a backup, here was a solution.
It was well known (or should have been) that distributing these was illegal, and this was in fact why I didn't allow posting links to these sites on the Tivo Community forums, back when I was running the Underground forum there. But they were well known nonetheless, and I myself sent links to abs.net to users in need.
Tivo is well within their rights to not have these images distributed, but it's a pretty sad thing that they now feel the need to exert those rights. I guess it's finally happened and Tivo is no longer "hacker" friendly. Oh well. It was a joyous time while it lasted, I guess.
I'm not familiar with TiVos in particular, but does anyone have any proof that they've made no derivative works from userland code or the Linux kernel without releasing source code to the modifications?
a) Tivo does distribute their kernel changes. See http://www.tivo.com/linux/index.html . There's enough there to build a Tivo kernel with a lot of effort on the user's part. In the case of later Tivo's you can't build your own *working* kernel because you can't sign the code, but there's ways around that.
b) Most of their code runs in userland, not in the kernel. This includes the MFS filesystem stuffs, AFAIK.
Essentially, it's just checking key variables like "GALLERY_BASEDIR" to make sure that they're not set in the input. If they are, it suicides. Any variable which is dangerous they can then simply add to that array at the beginning of the file.
Slashdot Mirror
FYI, if you are capable of performing this particular hack, it's a matter of about 10 seconds to restore it to functionality with OnStar.
The hack itself involves the following steps:
1) Solder a serial cable onto the GPS unit.
2) Hookup a laptop
3) Send a command that sticks the GPS unit into a different mode (NMEA) which is standard and works with all the mapping software you could want.
Getting it back to working with OnStar involves:
1) Sending a command to it to stick it back into Motorola binary mode
2) Unplug the laptop
You can leave the serial interface there. It doesn't mess with anything. And OnStar will work just fine once the GPS box is back in the mode that OnStar expects it to be in.
So your resale value isn't really an issue here. Admittedly, you can ruin the thing if you screw up the soldering, but the soldering part on this one isn't particularly difficult to do.
'til daddy takes the T-Bird away...
OnStar doesn't track the cars continuously. Anyone with half a brain could deduce that from the evidence.
a) It has an analog cell phone
b) All communication goes through the cell network
c) Using the cell network costs $$$
The way it works is that when you press the OnStar button, the cell phone calls home and connects you with a rep. The GPS data is transmitted at that time in case you want directions or something.
It also calls home in the event of an airbag deployment. (In the case of newer model GM cars, this connection between the car's class 2 network and the OnStar box is actually through the radio's wiring and so it may not work if you put in a third party radio without using the proper wiring harness, which bypasses the radio connection.)
While it's true that OnStar can call your box directly (such as if you want to unlock your doors or in the event that your vehicle is stolen and they want to track/disable the car), there's no real benefit for them to know your location at all times. How is them knowing where you are helping them financially to the extent that they would pay money for the call to your car to gather that data? It's not like the data can magically appear on their system without some form of transmission from your car to them. They have to contact your car and get that data, and that means the cellular networks will want cash for them to do that. So that data would have to be more valuable to them than the cost of the calls to the car.
This is likely because VW's are shit. If it's that easy to fry their diagnostic equipment, then why in the hell don't they put an opto-isolator inline with the diagnostic box's connection and prevent all electrical surges from making it to the diag box? Because they are idiots, that's why.
The radio and OnStar and such is tied together in GM vehicles too, using what is known as a class 2 network. Basically, there's a single wire running to every module in the car, including the radio and the OnStar box (and even the CD Changer if you have a factory one). They all communicate with each other using the J1850 VPW protocol. Yes, I suppose that if you ran some large amount of voltage on that wire, you could conceivably fry the modules, but then the car wouldn't work anymore in a fairly obvious way and so you really wouldn't have a hard time figuring out the problem. Certainly the computer wouldn't figure it out by hooking it up, since there's nothing for it to talk to in the car anymore.
Anyway, this guys mod is pretty basic and doesn't involve tinkering with the "brain" of the OnStar box in any way. All he did was to solder a serial connection onto the GPS board and then disconnect that board from the OnStar system. The GPS doesn't talk to the rest of the car directly, it goes through the brain unit. So nothing this guy does to the GPS can really affect the rest of the vehicle. It's not connected to the rest of the vehicle after he's done with it. Except insofar as it's drawing power from the vehicle.
As always, if you don't know what you're doing, you shouldn't mess with your car's electronics. But if you're inclined to tinker with your car, and you are capable of understanding electronics, it's not really difficult to figure out how this stuff works. This isn't brain surgery here, anyone with rudimentary electronics skills can work it out and get stuff to work correctly. If it was all that complicated, mechanics wouldn't be able to do it (no insult to mechanics intended, they simply have more of a mechanical viewpoint instead of an electronic viewpoint in very general terms).
This is definitely FUD on the part of GM. The Magnusson-Moss Act of 1975 specifically addresses this. Mainly, while modifying your OnStar system may void the warrenty on the OnStar box, they need to be able to *prove* that your modification was the actual cause of whatever is wrong with the car before they can claim that it's not covered under the warrenty.
This isn't all that new. All that it is really doing is building a serial interface onto the GPS part of the OnStar module and letting you access the data directly. Why bother?
1) The data is there already. It's cool to have access to it.
2) Many people, myself included, find OnStar somewhat useless, and don't pay for a subscription after the first free year. So it's nice to get some use out of that hardware that was already in the purchased vehicle anyway.
3) Using the built in GPS unit means no visible GPS antenna or hardware or what have you.
4) Because you can.
There's other parts of the OnStar hardware that are kinda cool too. The thing is basically a brain unit hooked to an analog cell phone and a GPS receiver. There's a built in microphone (in my case in the rear view mirror) and a connection to the car stereo system (both for audio and data, data being to display information on the radio display). Mainly I've been trying to hack the thing to let me use my own cell phone with the unit and thus make hands free calls, using the brain unit for the voice dialing functionality and so forth. Thus letting me make calls on my own phone without pahying the buck a minute charged by OnStar for their phone service.
Hey, the box in the car is *mine*. I paid for it, and I can do as I please with it.
Urm... would you let someone else dial into your network? I wouldn't let you into mine.
You're not a library and I'm not a local LUG offering you free hardware and software in order to benefit your customers.
Librarians are not sysadmins.
But it's the GPL, not Copyright Act that states the proprietary code needs to be released as GPLed open code. Why couldn't a judge order them to do that? It's not unthinkable.
Actually, it is, because the infringer still has a choice. Either they can agree to the GPL, in which case they have to GPL the derived code, or they can disagree with it, in which case they have to remove the GPL'd code entirely. The judge cannot force someone to agree to the license, the most he can do is force them to stop infringing by using the copyrighted code.
The suit the GPL'd code's author brings will be a copyright violation suit, because that's exactly what the infringer will have done. Used copyrighted code without permission. There's no contract for the GPL'd code's author to enforce. He hasn't gotten their agreement to the GPL. They can always agree to it or disagree to it, as they choose. It's just that whether they are infringing his copyright or not hinges on their agreement or disagreement.
This is a good idea. Especially if the library has broadband internet access (as many do nowadays). The local LUG could then administer the box by providing updated images to it remotely.
I figure that with just a bit of effort, you could make a small tabletop version of this for under $1000 or so. I mean, all it needs is a cheap system, a burner (preferably without a tray, as they tend to get broken in public places), and a monitor. Form factor could be exceedingly thin with a custom casing for it, esp. if you used an LCD panel for the screen.
Thin and small is good here, because that means it's not taking up space in the library, which would make getting the librarians to agree much easier.
Write some custom software to basically provide a menu of images that the user can pick from (and optionally allow the local LUG to remotely administer the thing), assure the librarian that it's all open source software (which entails explaining OSS to them), get their agreement and assure them that it's no maintainance at all for them (plus let them sell blank CD's/DVD's on a markup, and it'd be done.
Actually, let me rephrase part of that.. The purpose of the diplexer is to block the DC current from the receiver from hitting your TV tuner. Most diplexers don't block the frequencies from hitting the tuner (although they can, I guess), they just block the DC power, because that definitely would be bad for the TV tuner. If it wasn't for that DC power signal, you could use a normal splitter and it would work just fine, most likely.
Do you know of any other these multiswitches that DOESN'T require a diplexer at the output end to split the antenna/cable from the satelite. I was thinking of using one of these ( and I would be only using the satelite inputs; no cable/antenna ), but that drawback is a major PITA.
You don't need a diplexer at the receiver end unless you want to get that antenna signal off the wire. You can feed the combined sat+antenna signal into a receiver with no ill effects whatsoever. The sat receiver isn't tuning the low band antenna stuff, and so it's irrelevant to the receiver. The reason for the diplexer is to a) split the cable and b) block the high frequency satellite stuff from hitting your television, because it could be bad for the TV tuner. The satellite's tuner doesn't care.
And if you have no antenna hooked up to the switch, it's irrelevant anyway.
I dunno about an office setting, but as a developer, I use Access whenever I'm prototyping a new database. It's easy to create a new database, easy to access through Jet, and easy to modify on the fly when I screw it up. It lets me work out my table structures and run test queries using my programs or directly via the SQL. Okay, I have to work around its fucked up SQL if I work with Access directly, but the Jet engine's SQL seems to be mostly standard and works much differently from Access's SQL builder crap.
Anyway, once I've determined how I want it to work, then I can build the same structure using a real DB, like mySQL or Oracle or whatever. Converting my code to then use the new database is fairly quick and easy.
Access is fine for prototyping and testing, but I'd never use it in any real situation. Maybe if I was making a simple shareware program and needed a database that would work on most all Windows boxes, but that's about it.
We've also used Access in small intranet web applications, where the data isn't all that critical and we just need an easy way to access and display it to the members of the team, and the capability to easily modify it as needed. It's quick to develop for and works well enough in small-scale stuff. Sure, the time could be put in to make a real system, and it would have a lot of advantages if we used a real database, but we're talking throwaway code here, developed quickly to accomplish a goal that won't be around all that long, sort of thing.
I dunno.. if the efficiency per photon remains constant the temperature shouldnt increase. "in theory" you should be absorbing and emitting the same number of photons per second as a normal window would.
Yes, but only once light had passed through the thing. I mean, let's say you create a pane of glass that takes a year for light to pass through. For the first year, it's going to be as black as black can be, because it hasn't had time for the light to pass through it. Temp will increase all for that year. It would reach maximum once it started emitting, I grant you.
Interesting story, I grant you, but if such a thing existed, you'd have to wonder at the temperature the glass would reach after absorbing light for a few years. It'd be possible to do something similar to it using other methods, but I doubt the possibility of doing it using anything similar to the methods described in the book.
I think you read too much into my statement, but you're not alone there, so I don't fault you for it. I didn't mean anything along the lines of "hackers will destroy Tivo!" or anything similiarly stupid like that.
What I meant was simple, although badly expressed.
Tivo's latest offerings are oriented more towards technical things. HMO has things like web access to your box, MP3 and photo viewing, network and internet dialing, show sharing over a network, etc.. All off this stuff isn't what non-techie moms and pops are going to be doing, but it is an attempt by Tivo to get income. If Tivo hackers don't see a reason to "back off", then they could duplicate this sort of functionality on Tivo boxes for, essentially, free, and thus undermine Tivo's latest attempt, and perhaps any future attempts, at generating income.
Now I'm not saying anyone would do this intentionally, but in the past, Tivo's semi-hacker-friendly attitude has been just about the only thing stopping people from directly messing with anything related to Tivo's income. It's why people didn't mess with the service. It's why nobody has directly gone and done something more damaging to the advertising. It's why the information on how to clone serials and thus steal service properly isn't all that widely distributed. It's why the Tivo dialup service emulator programs are mostly limited to Canadian users, despite the fact that it could essentially replace the service functionality for every box out there and totally undercut Tivo's revenue. It's why nobody has really seriously tried to enable HMO without paying the $99 fee (and that one isn't even all that difficult to do, really).
There's a lot of ways that hackers could hurt Tivo by accident or by design, and hackers have generally taken the stance of limiting or not releasing things that could be potentially damaging. They liked the company, they liked the hardware, they granted that Tivo should make cash off it since it's a cool box and a cool company.
If that attitude changes, then some people may not restrict themselves so much in releasing software that has the *potential* to undercut Tivo's income stream. With, for example, a service emulator, I could run the emulator on my box. The Tivo would "dial in" to my own machine, get its guide data from there (which could be culled from online sources, which are free), and thus I'd have full functionality without paying Tivo one thin dime. Such software exists, but is limited in scope and distribution because hackers like Tivo. And that's because Tivo hasn't tried to stop hackers. They've generally said "hey guys, knock yourself out, but there's limits, okay?" in the past, and if that changed, well, it wouldn't be a good thing for anybody, would it?
lkml.org seems to be having issues. Here's a link to the google cache of that post where Linus talks specifically about signed kernels:
Google Cache
Then the source code, as defined by the GNU General Public License, is not complete. The GPL defines the "complete source code" of an executable work as "all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." If compilation and installation of the executable includes a digital signature, then it could be argued that the scripts would have to include the private key used to sign the executables.
It's a fine point, actually. You are more than welcome to compile a Tivo kernel and run it on your own hardware. But newer Tivo hardware requires a kernel signed by Tivo (the BIOS checks the signature on the kernel before it will boot it). Tivo's hardware is the one enforcing the signature check here, and they don't have any obligation, under the GPL, to provide the ability to sign code to run on their hardware. So they have fulfilled the GPL to the extent that you can compile and use the code on any normal hardware, but their hardware is special.
It's a bit of a tricky point, methinks. None of their *code* is checking the signature. Their hardware is. The Tivo kernel you compile will run just fine, on any hardware you happen to get it to run on. You can install it on any hardware you have all day long. But it's debatable as to whether they have to provide you with the capability to run it on their proprietary box though.
don't know where you got your information, but HMO is NOT a subscription based service
You are correct. Sorry, my mistake. I don't have HMO and don't have a series 2 unit, so I'm not fully up to date on it's offerings or such.
Boy, you sure can read between the lines.. Badly, I might add.
business model is based on extorting a monthly fee for a VCR
With the standalones, it's not all that unexpected.. The unit needs continuing guide data, Tivo provides that data. Value received for payment made. With the D-Tivo's you have a point, but the fee on the D-Tivo's is so low that it's not even worth thinking about it.
acting like a jackbooted thug and violating the GPL
Tivo isn't violating the GPL, in even the most restrictive sense you can possibly put the GPL. They're totally in the clear on this one.
you're saying that you're surprised
I'm surprised in that I'm not sure what this particular action gets them in terms of a gain. It's one thing if this was costing them subscriptions or sales, but it's not, as far as I can see. So I fail to understand why they took this course, because it gains them nothing of import.
DirecTivos don't do their software updates over the phone, they get them from the satellite, then dialup to verify that the machine is active, then run the patches. I can't be 100% sure, but the standalones and the DirecTivos are completely different, so there's no way to just magically make HMO (Home Media Options) work.
Not yet they don't.
DirecTivo's still get their software updates over the phone line. The capability exists to do software patching via the satellite, but to my knowledge (admittedly limited on this point), they have not used it yet.
And the "magic" way to make HMO work on Series 2 D-Tivo's is indeed to copy a Series 2 standalone image with activated HMO to the unit. This was discovered a few months ago. Tivo unified their code base with the series 2 systems a while back, and one side effect of this was that the code became unified enough to where the standalone image was in fact "close enough" to work more or less correctly on a D-Tivo. Doing this and letting it then dial in would be an exceedingly stupid thing to do, but no doubt some morons did it anyway.
This highlights a bit of a problem with Tivo's latest offerings, one that I bitched about on the Tivo Community forums back when I was still welcome there. They are charging, on a monthly basis, for what is essentially a one time software update. Every feature of the HMO (Home Media Option) stuff, with the exception of web access to your Tivo, is done by the unit itself and requires no external connection as such. The MP3 playing, show sharing, picture viewing, all of that doesn't need the unit to call home to be able to do any of it. So it was really only a matter of time before someone flipped their own switches on the box, I argued. The unification of the code base between D-Tivo's and Standalones let people figure out how to flip their own switches on the D-Tivo's as well. Take an HMO activated standalone, copy it to the D-Tivo, voila.
Tivo is headed down the drain, IMO. They made a very good product, and changed the landscape of TV viewing. But they've made some very poor decisions with regards to their business strategies and software designs, and now it's starting to bite them in the ass.
I'm starting to feel like it's only a matter of time before it's full on war between Tivo hackers and Tivo Inc., and Tivo Inc. doesn't stand a chance on this one. The majority of Tivo sales have classically been via word of mouth, and if they don't turn it around, they're going to alienate their best and most vocal sellers, ya know?
I haven't seen TiVo's userland code, but I expect it's tightly tied to their own libs and module code.
/dev device interfaces which any program can use, type of thing. It's a pretty good layer of separation, in other words.
You'd probably be wrong there. I haven't seen the actual userland code either, but I have messed about on the Tivo extensively, and it's not "tightly" tied by any means. They do have modules for the hardware which they have released, I think, but these provide more or less normal interfaces to it for the most part, and there's little need to compile their headers and such into the userland code and so forth. The kernel modules mostly just provide
But if they've added drivers for TiVo specific hardware (don't know if there is any, don't have a TiVo) then it's down to the old binary modules argument, and if they've modified the kernel in any way then they need to release those modifications.
There is and they have. http://www.tivo.com/linux
The objection to distribution of images is that image necessarily contain their proprietary userland code, which is decidely not GPL.
I suspect their concern is that someone will figure out how to hack their way into their servers
Already done, but easily detected on their end, more or less.
or steal DirecTV service
Also already done, and not easily detectable either. But it's no easier than stealing DTV on any other DTV box.
or eventually manage to run the whole image on "stock" hardware.
Not bloody likely, and considering that this particular site has been in operation *at least* three years to my explicit knowledge, nobody is really interested.
I know a lot about Tivo and the hacking community and such, and I'm at a loss to satisfactorily explain why Tivo would do this. I suspect a Tivo lawyer found out about it. Most of the Tivo engineering people have no real issue with this sort of thing.
Tivo is well within their rights here, but to my absolute and certain knowledge, several key people at Tivo have known about ftp.abs.net for at least 2 years. I'm just not sure why this is happening now.
That's more or less exactly how these images were made. Early on, images were made using dd. Nowadays, people make images using a special program called "mfstool" which is capable of backing only the necessary parts of the Tivo drive, reducing the size of the created image. So all the sites recommend making your *own* image. But sites like abs.net existed as a just in case type of mechanism. If your system failed, and you never made a backup, here was a solution.
It was well known (or should have been) that distributing these was illegal, and this was in fact why I didn't allow posting links to these sites on the Tivo Community forums, back when I was running the Underground forum there. But they were well known nonetheless, and I myself sent links to abs.net to users in need.
Tivo is well within their rights to not have these images distributed, but it's a pretty sad thing that they now feel the need to exert those rights. I guess it's finally happened and Tivo is no longer "hacker" friendly. Oh well. It was a joyous time while it lasted, I guess.
I'm not familiar with TiVos in particular, but does anyone have any proof that they've made no derivative works from userland code or the Linux kernel without releasing source code to the modifications?
a) Tivo does distribute their kernel changes. See http://www.tivo.com/linux/index.html . There's enough there to build a Tivo kernel with a lot of effort on the user's part. In the case of later Tivo's you can't build your own *working* kernel because you can't sign the code, but there's ways around that.
b) Most of their code runs in userland, not in the kernel. This includes the MFS filesystem stuffs, AFAIK.
Essentially, it's just checking key variables like "GALLERY_BASEDIR" to make sure that they're not set in the input. If they are, it suicides. Any variable which is dangerous they can then simply add to that array at the beginning of the file.