Last time I installed XP (about three weeks ago), you don't have a choice in installing WMP. It's there by default, with no way to remove it (well, you can remove the shortcut, but the DLLs and stuff are still there). If I recall correctly, Windows 95 and 98 allowed you to remove it, since they presented an itemized list of what to install.
2000-XPLite, on the other hand, does look very promising in that it did wonders for Windows 98. But, back then, everything wasn't as dependent on Internet Explorer (and WMP).
My apologies for sounding like a jackass in my previous response... But I must say that my MythTV installation works great.
Now, granted, I don't use all of the features of MythTV, but I use the TV/recording, DVD/VCD playback (MythDVD), weather (MythWeather) and MythGame (for MAME only) modules on a regular basis only, but I have in the past tried out the music and video modules as well.
Like I said in another post, setting up MythTV used to be a real pain, but if you have hardware similar to that which Jarod uses (PVR-x50 for video capture and Nvidia GeForce 4 for TV-out), then you should have very few problems with the setup. Note that I didn't buy hardware that matches his list because he wrote it, but I did lots of research in the mailing list archives. I originally started out with a Matrox G400 for TV-out, and a pair of BT878 capture cards. As I decided I wanted a better picture and better performance, I started replacing hardware. My MythTV machine was basically built from scratch (but that's because the only other CPU I had here wasn't fast enough for software encoding, and the motherboard is a KT133A - known DMA problems with PVR-250 cards).
On the Windows side, you might find that it's easier to build a PVR, due to better driver support, but I think that you'll still run into trouble if you try to just use spare parts and slap something together (unless those spare parts are really good spare parts).
Using Jarod's guide (URL in another post), I can setup MythTV from scratch in less than eight hours (assuming the supported hardware from the guide), although I think my last clean installation was four hours. (In fact, I recently did this, as I replaced the hard drive in the MythTV machine).
Then again, I have 3Mbps downstream on my cable modem (thank you, Comcast!), so the downloading doesn't take that long. Using apt-get handles all of the dependencies, and the RPMs are setup with most of the default paths. Also, my hardware is very similar to that of Jarod's.
The problem with supporting digital TV is that there is no particular standard for it (at least not in the United States anyway). Secondly, the signal is usually encrypted, and only the digital cable box is meant to descramble it.
MythTV has a half-decent solution, which is to allow you to send a command to your digital cable box, either by serial port (if your digital cable box supports such a thing), or by using an IRBlaster (the solution that TiVo uses, if I understand correctly). Then again, I use two PVR-x50's (one PVR-250, one PVR-350) with analog cable, so this isn't an area that I'm all too familiar with.
Seeing as the software houses that write this software are in the United States, they're most likely to cater to the U.S. audience. Testing non-U.S. equipment would certainly be a challenge (although not impossible).
MythTV used to be a major b*tch to setup, I remember compiling the tarballs, pulling in all of the dependencies by hand, etc. It was quite painful (this was back around 0.9, when I started using it).
However, now that Jarod has put up his excellent website on setting up MythTV with Fedora Core 1, and Axel builds RPMs, it's a no-brainer. And, at least for me in the United States (California), XMLTV hasn't broken in months. And, thanks to the crack programmers, there's an option to check on the status of the last XMLTV grab (and MythTV e-mails you also).
Now of course, if your hardware deviates from the website, then you might have a problem. But, for the most part, it's still pretty easy.
Slowly but surely, OSS is getting out there. My anecdotal evidence: One of my co-workers was using Internet Explorer (under Windows XP), and complaining about all of the pop-up windows. I brought him over to my Windows 2000 machine and showed him Mozilla. I told him about the pop-up blocking, showed him the little icon in the toolbar that is displayed when pop-ups are blocked, and showed him tabs. Just a quick demonstration, maybe two minutes at most.
He switched that afternoon. About a week later, he went up north to visit some of his relatives. When he came back, he told me how he showed them Mozilla's pop-up blocker, and his relatives switched too!
So, I think that little demos are the way to go. Don't pressure a switch to Linux, work at switching the applications first. Once the person is standardized on running applications that exist on both Windows and Linux, then they might be more comfortable with Linux.
My guess would be probably not. And yes, although I'm a cynic, the reason I say this has nothing to do with the DoJ possibly letting it slide.
If I recall correctly, most of the original slap against Microsoft with regards to Java, was that they played dirty. In this case, Microsoft actually isn't playing dirty (from what I see thus far), they're giving out the information (at what monetary cost, I don't know) to application developers on how to prepare their applications for the new Service Pack.
Therefore, Sun doesn't really have any grounds to take them to court. As long as Microsoft publically announces what they're doing, and makes the information to the application developers, then it is Sun's responsibility to make Java work with Service Pack 2.
Personally, I think it's in Microsoft's best interest to not do work-arounds for any applications, but rather just publish the information, and give the application vendors some time to prepare the fixes. At least in that way, Microsoft can be seen as being neutral, and not playing favorites. If application "foobar" doesn't work under SP2, then at least Microsoft could say, "talk to the application vendor". Whether or not that would be a big blow against Microsoft, well, it's hard to say.
I think what they're referring to is self-modifying assembly code - the code rewrites itself as it runs for one purpose or another.
I haven't done any 80x86 assembly language since my second year of university, but back on the Commodore 64, if I was doing something and needed a lot of counters, it was easy to run out of registers. So, sometimes I'd just re-write the value of a compare statement, or a branch instruction to get the code to do something different, so that I didn't have to push a whole bunch of registers to the stack and stuff like that.
Today though, there's probably code (like copy-protection code) that decrypts itself before/while running, or maybe even decompresses itself before/while running. The CPU/Windows XP SP2 is likely to prevent this from working, because you're trying to modify the program segment (which on newer CPUs, I thought, was meant to be non-modifiable - that's what the data segment is for).
It's quite possible to not believe that a contract is valid, yet follow the terms of it. Validity of, and compliance to, a license/contract are not mutually exclusive.
Depending on the situation, you might comply to the terms of a contract (if you have no other choice), to cover your butt, while at the same time challenging it in court.
While improvements to Linux are a community process, Linus has the final say.
Yep, Linus has the final say on kernels that go out with his name. But there are other kernels out there that are popular, have you heard of the "ac" kernels? That's "ac" as in Alan Cox, and he regularly releases kernels that have things in them that Linus hasn't blessed for his kernel, for whatever reason, and AC feels that the items are worth having.
Look, I agree, someone could try to fork it.
You're certainly welcome to fork the kernel. And if people like the changes you made to it, you might end up at a level like Alan Cox, and his mentioned "ac" kernel line.
But realistically, practically speaking, the only Linux that exists (and thus the one that most manufacturers will even consider writing a driver for) is the one that Linus is in control of.
Well, then, I guess you have to provide some good incentive to those manufacturers. But a stable ABI that allows them to make one buggy, binary-only driver, and never have to update it should be a great incentive, shouldn't it? They'd love a one-time investment, like they do for Windows (for each version of Windows, that is).
I haven't proposed a solution, but Linus definitely has a lot more say on these sort of issues regardless of technical merit or desire of Linux users. It's a level of control that isn't exerted through ownership of the copyright, but at the same time, he retains a certain amount of power over it (not to the extent that someone who retains copyright over a piece of code holds).
Of course Linus has the final say, he wrote the damn thing! And he attaches his name and reputation to every kernel release that he makes, therefore, it's in his best interests to make sure that he releases something that is stable and works (although sometimes that doesn't happen).
Linus has always been quite vocal in stating that he will look at patches, and if it's not something he's interested in (either becuase he's truly not interested, or because the section of code you're changing is maintained by somebody else, or he feels your patch has bugs, or poor style, etc.), he'll often suggest to you who to send it to.
To quote a line from a movie, "This isn't a democracy, it's a cheer-ocracy". Now, change "cheer-ocracy" to "code-ocracy", and you have the general idea. It's not what the general public thinks is best (otherwise ALSA and esound would have been part of the 2.4 kernel as I suggested back on the LMKL during the development of 2.3), it's what the core contributors to the kernel feel is best. If that conflicts with what you think is best, then you have to convince them - I hear money works well.
If the users of Windows want features implemented (or certain features not implemented/removed), then they need to harass Microsoft, not complain about Linux having poor hardware support. If Microsoft doesn't listen, then you need to either put up with it, or stop buying Microsoft products. And if Linux doesn't work for you, then complain to the people you bought it from (i.e. Red Hat or Mandrake, etc.). If you didn't buy it, then about the best you can do is politely ask, but don't expect anything.
First, I must preface this by saying that I'm not a kernel developer, so I'm in no way speaking for any of them.
You're absolutely correct that it's a political message to the closed-source developers. And I must say that I completely agree with it. The whole idea of Linux and the GPL is "share and share alike", and the creators of binary-only drivers are only taking, they're not sharing (providing a binary-only driver to me, is not sharing).
The kernel developers are not resticting your rights to run your PC as you wish in any way, nor are they preventing you from using hardware with closed-source drivers. If you want to, you're completely free to. But, don't expect support on the mailing lists when the binary-only driver crashes the system. Additionally, the creators of binary-only drivers should not expect support from the kernel developers.
From what I understand, the kernel code that is not available when the GPL license isn't followed isn't anything earth-shattering, and the driver maintainer can always re-write it using the GPL'd code as a guideline.
Yes, Linus is against binary-only modules. He also states that he will not put a mechanism in place to make it easier for programmers of binary-only modules.
But, the kernel is released under the GPL, he can't stop you from writing an ABI that allows you to do this. So, while he doesn't want do the work for you, he gives you the freedom to do it if you wish. I don't see how he's inconsistent with the principles of free software. He just doesn't want to do it, nor does he have to.
If jane_hacker can't roll her own kernel, that's not Linus' problem. He gives you the kernel, what you want or are able to do with it is your problem, not his.
Maybe if you offered Linus (or somebody else with the skills) some money to write code that creates a standard ABI to make binary-only modules work, some work would be done on it.
As a final note, Linus started the kernel, it's only fair that he should be in control. If you don't like his level of control, then the GPL gives you the freedom to fork off the code and do with it as you will, as long as you release the source to the changes.
Yes, they make that claim. However, I have tried some programs in the past that did not work, because they used fastloaders.
The Commodore drives have five wires on the serial port (I think). Of those, I think only two of them could send data. One was the DATA line, the other the CLK line.
So, when the C64 was reading a file from the 1541, it would receive the bits one at a time over DATA, and use CLK to synchronize. This of course, was extremely slow, so somebody came up with a solution: send data over both lines, but make sure that the code on both sides was running at almost exactly the same speed.
So, the drive would break down the byte into bits, and send two bits at a time (when using the fastloader). The C64 would receive the two bits and reassemble them into the byte. But, since the CLK line was being used for data, the timing had to be precise, otherwise you'd miss bits.
So, the emulator has to emulate the drive and the C64 with 100% compatibility, or else it just won't work. Also, because sprites would mess up the CPU cycles, they had to be disabled, as did any funky IRQs (which normally there weren't any running), or you'd have problems with the data. Most fastloaders just blanked the screen, which took care of this.
Actually, the autoloading was usually done by machine language programs. The typical way to do it would be to write a small stub program in machine language that loaded into memory space near the I/O vectors (the cassette buffer and a small little area at $02A7 were favorites). As part of that program you would actually save a copy of the vectors, and set the load address of your executable to be that of the vectors.
When your program loaded, you overwrote the vectors, and one of them controlled where program execution went after a load.
It's been a long time since I've done that, so the exact details in my mind are hazy. But that's how some of the simple autoloaders were done.
I haven't done this yet, but I would imagine that you could create.D64 files (disk images), and use them.
However, it's hard to say whether or not this would work with an emulator or not. GEOS used fast-disk routines that ran in the drive memory of the 1541/1571/1581 drives, and if the emulator can't emulate the CPU in the drive (6502 in the 1541) and the 6510 in the C64 with 100% cycle exactness, then you'll have some problems.
As for the ",1", well, it went like this. The first two bytes of every standard file that was designed to be loaded using kernel routines (whether it be from the BASIC LOAD command, or through the actual kernel routines) were the load address. Most basic programs were loaded into memory at $0801, so those two bytes (actually $01, $08) were at the beginning. If it was assembly code that loaded into memory at $C000, then the first two bytes were $00, $C0.
Anyway, to make a long story short, that ",1" told the load routines to load the file into the memory space pointed to by those first two bytes. Otherwise, they would be ignored, and the program would be loaded into memory at the start of BASIC memory (by default, $0801, but I think memory locations 43 and 44 changed that).
My setup was a Commodore 64C, two 1541 disk drives (one 1541, and one 1541-II), and a 1764 RAM Expansion Unit (256K). I used a program called Maverick (which included a utility called geoBoot I think) that would allow me to make custom boot disks for GEOS - once the GEOS kernel initialized, Maverick would interrupt it, and dump it out to floppy, thus making a 30KB or so program to run.
Those were the days... I learned some of the GUI programming concepts that I use today in writing a Desk Accessory (a word counting program for geoWrite). I loved the environment of geoProgrammer, although using geoWrite for a source code editor was a bit painful (but, with the REU, it wasn't so bad).
Hmmm, I wonder if this would work under VICE? The GEOS fast-disk routines were very timing specific, so it might not. Maybe I'll give it a try.
The problem is not necessarily that there's too much code, but that their code is a patch to a patch to a patch to a hack to a patch. (I'm quite familiar with this, some of the source code for the product I work on is like that too. It does get to the point where I just rewrite a module.)
It's like bolting on a new piece of metal to bridge when a hole comes in or something. Rather than replace an entire beam, they just keep patching the holes.
What Microsoft needs to do is replace areas that have too many bugs. It won't happen though because there's too many applications out there that might break (some applications "know" or "detect" the bugs and work around them), and that would be bad.
DOCSIS 1.1 and 2.0 do address some security concerns (like tricking the cable modem into grabbing a config file from the Ethernet port instead of the cable port), but if I understand the article (and the website of TCNISO), they have access to the serial port. Once you can issue commands at the vxWorks shell, you can pretty much figure out how to get around the security checks.
Oh, and yes, DOCSIS 1.1 and 2.0 *allow* firmware to be signed by the cable company (or by the cable modem vendor), but, the operator has to specifically enforce this, it's not automatic. And I've received requests from cable operators for unsigned firmware for DOCSIS 1.1 modems. Just like the MD5 that everybody talkes about - yes, the config files are verified with an HMAC-MD5 hash, but if the operator doesn't put in a good "shared secret" for the hash, then you have no security.
Here's the catch. The cable operators don't want you seeing the power level and the SNR (or your caps for that matter). Not everybody out there knows what these numbers mean (hint: SNR as high as possible, power level between 0 and 48, give or take, around 30 is good, I don't remember the numbers on the negative side). If you get two people who don't know what these numbers mean, they'll compare numbers, and suddenly the cable operators are flooded with calls like, "Hey, John's SNR is higher than mine, fix it now!". It's an added support burden on them, and they can't always fix the problem (many times, it's an issue with the coax wiring in your house).
CableLabs also has a list of parameters that aren't supposed to be viewable by customers, I don't remember off hand everything in that list (I know that the IP address of the modem is definitely one of them, I don't know about power level and SNR).
The problem with showing end-users the caps is that even though you may be capped at say, 1Mbps downstream, you might not be able to pull that in when everybody in your neighborhood is using their cable modem. Again, somebody might call in and ask why their measurement tool of choice isn't showing 1Mbps and demand it be fixed.
As for SNMP... Well, currently, SNMPv1 and SNMPv2c are used in cable networks, which is very insecure. Some operators might be using SNMPv3, but I haven't heard of anybody using it. SNMP security on modems is very weak, you can look at RFC2669 for some info as to what modems support for SNMP. The basic goal, unless you're using SNMPv3 is to setup groups of subnets and community strings that give read, write or read/write privlidges. All uncncrypted. Very weak security, really.
If they find a customer who they think has uncapped their modem, have the support staff set their NAC (Network Access Control) in the config file to 0 (03 01 00). The modem won't be able to pass traffic from the machine(s) behind it, and the customer will surely call you to find out why they can't get online. This assumes that they're still pulling down a config file from you, if your tech team has the "shared secret" enabled, it should be virtually impossible for them to create/edit the config file themselves (because then the HMAC-MD5 digest won't be correct).
You can then talk to the customer in more detail to see what's going on.
I'm still monitoring this story for interesting responses. I work in the cable industry, so this is big news for me and the company that I work for.
Anyway, a lot of the equipment in the field is older, and at the moment, I don't know of any cable modem, or CMTS chipsets that actually provide hardware encryption capabilities, therefore it's done in software. BTW, the data is encrypted only between the cable modem and the headend (CMTS), therefore all the encryption protects you from is somebody setting up a CATV sniffer somewhere between your house and the cable plant. Since that equipment is relatively expensive (last I checked, $30K), your chances of being sniffed are pretty slim, unless as you said, Joehacker turns his cable modem into an RF sniffer (definitely possible).
The encryption (BPI/BPI+), while doing encryption, also performs a more important function (especially BPI+) - they give the cable operator an element of trust, in other words, if you say that you have the "Foo XYZ" cable modem hooked up to their network, they can tell by the crypto info that you in fact do have that modem hooked up (or they can tell that you have "Bar ABC" hooked up. This is somewhat important to them, so that they can keep the "bad element" out of their networks.
BTW, the encryption isn't the only thing done in software. Like I said earlier, a lot of the equipment in the field is pretty old, so concatenation (which does what it's name implies, it concatenates packets before sending them upstream), while done in hardware on most Broadcom-based modems, is done in software on most CMTS'. This slows things down a bit as well (but the numbers show that concatenation really does improve performance, i.e. from 200 to 1000+ packets per second, 64 byte packets), so they use it heavily, despite the slower processing.
Comcast is doing quite well on the speed issue. I was previously provisioned to 1.8Mbps down, 256Kbps up, and I believe that I was recently changed to 3Mbps down/256Kbps up. I'm getting much better downstream speeds than I ever got from DSL.
I'm currently writing a wxWindows app under FreeBSD, but it compiles cleanly under MinGW (for Windows) as well. I haven't really had any problems up until now.
I'm curious to know what problems you had with it so that I can try to avoid them.
The TCNISO website mentions three Motorola Surfboard modems that this works with, the SB3100, the SB4100 and the SB4200. I guaran-damn-tee that these modems are all DOCSIS certified (Motorola advertises them as such, and cannot do so without CableLabs' permission, or else they could face some legal issues). The SB3100 is DOCSIS 1.0 certified (upgradable to 1.1), and the SB4100 and SB4200 are DOCSIS 1.0 and 1.1 certified. (I also verified their certification status with my contacts.) Certified DOCSIS modems have a green sticker on them with the letters "CL", and state "CableLabs Certified" (or use this in their marketing literature, or on the box).
A mistake that I made in the previous post - if the revocation takes effect, it will only pose a problem on operators running BPI+ (which they should do with DOCSIS 1.1). An operator running BPI (if I recall correctly, I may be wrong, I don't know the DOCSIS spec by heart) can't use the revocation list, since BPI only uses public/private key pairs, not exact X.509 certificates (note that operators can ban modems based on other methods than certificates, like MAC address). Nonetheless, if Motorola used the same CA to generate certificates for all their modems (a good possibility), a revocation of that CA means that all modems signed with that CA are useless in a BPI+ environment.
Most operators are still running DOCSIS 1.0, with or without BPI (note the "no comment" from many cable operators in the article), but many of them are planning to switch to DOCSIS 1.1 with BPI+ in order to take advantage of the extra functionality and security.
Disclaimer: Again, all of what I have stated is basically publically available knowledge.
I won't comment on the legality of this, because I'm not a lawyer. I don't know if it's legal or not.
It's quite possible that it would be a decent vxWorks development platform. WindRiver uses patched version of GCC (the patches mainly apply to specific variants of the processors), and I personally find the GUI project maker of Tornado (the client side tools of vxWorks) to be absolutely awful. Makefiles work much better.
However, in order to actually compile applications, you'll need the static vxWorks libraries, you'd have to figure out a way to extract them from the cable modem binary (I don't know anything about Motorola's firmware file format, so I don't know if you can do this or not) in order to link, short of buying the development environment.
So, it might help you learn some stuff about the vxWorks shell, but maybe not much else.
Slashdot Mirror
Last time I installed XP (about three weeks ago), you don't have a choice in installing WMP. It's there by default, with no way to remove it (well, you can remove the shortcut, but the DLLs and stuff are still there). If I recall correctly, Windows 95 and 98 allowed you to remove it, since they presented an itemized list of what to install.
2000-XPLite, on the other hand, does look very promising in that it did wonders for Windows 98. But, back then, everything wasn't as dependent on Internet Explorer (and WMP).
-- Joe
My apologies for sounding like a jackass in my previous response... But I must say that my MythTV installation works great.
Now, granted, I don't use all of the features of MythTV, but I use the TV/recording, DVD/VCD playback (MythDVD), weather (MythWeather) and MythGame (for MAME only) modules on a regular basis only, but I have in the past tried out the music and video modules as well.
Like I said in another post, setting up MythTV used to be a real pain, but if you have hardware similar to that which Jarod uses (PVR-x50 for video capture and Nvidia GeForce 4 for TV-out), then you should have very few problems with the setup. Note that I didn't buy hardware that matches his list because he wrote it, but I did lots of research in the mailing list archives. I originally started out with a Matrox G400 for TV-out, and a pair of BT878 capture cards. As I decided I wanted a better picture and better performance, I started replacing hardware. My MythTV machine was basically built from scratch (but that's because the only other CPU I had here wasn't fast enough for software encoding, and the motherboard is a KT133A - known DMA problems with PVR-250 cards).
On the Windows side, you might find that it's easier to build a PVR, due to better driver support, but I think that you'll still run into trouble if you try to just use spare parts and slap something together (unless those spare parts are really good spare parts).
-- Joe
Using Jarod's guide (URL in another post), I can setup MythTV from scratch in less than eight hours (assuming the supported hardware from the guide), although I think my last clean installation was four hours. (In fact, I recently did this, as I replaced the hard drive in the MythTV machine).
Then again, I have 3Mbps downstream on my cable modem (thank you, Comcast!), so the downloading doesn't take that long. Using apt-get handles all of the dependencies, and the RPMs are setup with most of the default paths. Also, my hardware is very similar to that of Jarod's.
Where do I collect my Nobel prize?
-- Joe
The problem with supporting digital TV is that there is no particular standard for it (at least not in the United States anyway). Secondly, the signal is usually encrypted, and only the digital cable box is meant to descramble it.
MythTV has a half-decent solution, which is to allow you to send a command to your digital cable box, either by serial port (if your digital cable box supports such a thing), or by using an IRBlaster (the solution that TiVo uses, if I understand correctly). Then again, I use two PVR-x50's (one PVR-250, one PVR-350) with analog cable, so this isn't an area that I'm all too familiar with.
Seeing as the software houses that write this software are in the United States, they're most likely to cater to the U.S. audience. Testing non-U.S. equipment would certainly be a challenge (although not impossible).
-- Joe
MythTV used to be a major b*tch to setup, I remember compiling the tarballs, pulling in all of the dependencies by hand, etc. It was quite painful (this was back around 0.9, when I started using it).
However, now that Jarod has put up his excellent website on setting up MythTV with Fedora Core 1, and Axel builds RPMs, it's a no-brainer. And, at least for me in the United States (California), XMLTV hasn't broken in months. And, thanks to the crack programmers, there's an option to check on the status of the last XMLTV grab (and MythTV e-mails you also).
Now of course, if your hardware deviates from the website, then you might have a problem. But, for the most part, it's still pretty easy.
-- Joe
Slowly but surely, OSS is getting out there. My anecdotal evidence:
One of my co-workers was using Internet Explorer (under Windows XP), and complaining about all of the pop-up windows. I brought him over to my Windows 2000 machine and showed him Mozilla. I told him about the pop-up blocking, showed him the little icon in the toolbar that is displayed when pop-ups are blocked, and showed him tabs. Just a quick demonstration, maybe two minutes at most.
He switched that afternoon. About a week later, he went up north to visit some of his relatives. When he came back, he told me how he showed them Mozilla's pop-up blocker, and his relatives switched too!
So, I think that little demos are the way to go. Don't pressure a switch to Linux, work at switching the applications first. Once the person is standardized on running applications that exist on both Windows and Linux, then they might be more comfortable with Linux.
-- Joe
My guess would be probably not. And yes, although I'm a cynic, the reason I say this has nothing to do with the DoJ possibly letting it slide.
If I recall correctly, most of the original slap against Microsoft with regards to Java, was that they played dirty. In this case, Microsoft actually isn't playing dirty (from what I see thus far), they're giving out the information (at what monetary cost, I don't know) to application developers on how to prepare their applications for the new Service Pack.
Therefore, Sun doesn't really have any grounds to take them to court. As long as Microsoft publically announces what they're doing, and makes the information to the application developers, then it is Sun's responsibility to make Java work with Service Pack 2.
Personally, I think it's in Microsoft's best interest to not do work-arounds for any applications, but rather just publish the information, and give the application vendors some time to prepare the fixes. At least in that way, Microsoft can be seen as being neutral, and not playing favorites. If application "foobar" doesn't work under SP2, then at least Microsoft could say, "talk to the application vendor". Whether or not that would be a big blow against Microsoft, well, it's hard to say.
-- Joe
I think what they're referring to is self-modifying assembly code - the code rewrites itself as it runs for one purpose or another.
I haven't done any 80x86 assembly language since my second year of university, but back on the Commodore 64, if I was doing something and needed a lot of counters, it was easy to run out of registers. So, sometimes I'd just re-write the value of a compare statement, or a branch instruction to get the code to do something different, so that I didn't have to push a whole bunch of registers to the stack and stuff like that.
Today though, there's probably code (like copy-protection code) that decrypts itself before/while running, or maybe even decompresses itself before/while running. The CPU/Windows XP SP2 is likely to prevent this from working, because you're trying to modify the program segment (which on newer CPUs, I thought, was meant to be non-modifiable - that's what the data segment is for).
-- Joe
Say what?
It's quite possible to not believe that a contract is valid, yet follow the terms of it. Validity of, and compliance to, a license/contract are not mutually exclusive.
Depending on the situation, you might comply to the terms of a contract (if you have no other choice), to cover your butt, while at the same time challenging it in court.
-- Joe
While improvements to Linux are a community process, Linus has the final say.
Yep, Linus has the final say on kernels that go out with his name. But there are other kernels out there that are popular, have you heard of the "ac" kernels? That's "ac" as in Alan Cox, and he regularly releases kernels that have things in them that Linus hasn't blessed for his kernel, for whatever reason, and AC feels that the items are worth having.
Look, I agree, someone could try to fork it.
You're certainly welcome to fork the kernel. And if people like the changes you made to it, you might end up at a level like Alan Cox, and his mentioned "ac" kernel line.
But realistically, practically speaking, the only Linux that exists (and thus the one that most manufacturers will even consider writing a driver for) is the one that Linus is in control of.
Well, then, I guess you have to provide some good incentive to those manufacturers. But a stable ABI that allows them to make one buggy, binary-only driver, and never have to update it should be a great incentive, shouldn't it? They'd love a one-time investment, like they do for Windows (for each version of Windows, that is).
I haven't proposed a solution, but Linus definitely has a lot more say on these sort of issues regardless of technical merit or desire of Linux users. It's a level of control that isn't exerted through ownership of the copyright, but at the same time, he retains a certain amount of power over it (not to the extent that someone who retains copyright over a piece of code holds).
Of course Linus has the final say, he wrote the damn thing! And he attaches his name and reputation to every kernel release that he makes, therefore, it's in his best interests to make sure that he releases something that is stable and works (although sometimes that doesn't happen).
Linus has always been quite vocal in stating that he will look at patches, and if it's not something he's interested in (either becuase he's truly not interested, or because the section of code you're changing is maintained by somebody else, or he feels your patch has bugs, or poor style, etc.), he'll often suggest to you who to send it to.
To quote a line from a movie, "This isn't a democracy, it's a cheer-ocracy". Now, change "cheer-ocracy" to "code-ocracy", and you have the general idea. It's not what the general public thinks is best (otherwise ALSA and esound would have been part of the 2.4 kernel as I suggested back on the LMKL during the development of 2.3), it's what the core contributors to the kernel feel is best. If that conflicts with what you think is best, then you have to convince them - I hear money works well.
If the users of Windows want features implemented (or certain features not implemented/removed), then they need to harass Microsoft, not complain about Linux having poor hardware support. If Microsoft doesn't listen, then you need to either put up with it, or stop buying Microsoft products. And if Linux doesn't work for you, then complain to the people you bought it from (i.e. Red Hat or Mandrake, etc.). If you didn't buy it, then about the best you can do is politely ask, but don't expect anything.
-- Joe
First, I must preface this by saying that I'm not a kernel developer, so I'm in no way speaking for any of them.
You're absolutely correct that it's a political message to the closed-source developers. And I must say that I completely agree with it. The whole idea of Linux and the GPL is "share and share alike", and the creators of binary-only drivers are only taking, they're not sharing (providing a binary-only driver to me, is not sharing).
The kernel developers are not resticting your rights to run your PC as you wish in any way, nor are they preventing you from using hardware with closed-source drivers. If you want to, you're completely free to. But, don't expect support on the mailing lists when the binary-only driver crashes the system. Additionally, the creators of binary-only drivers should not expect support from the kernel developers.
From what I understand, the kernel code that is not available when the GPL license isn't followed isn't anything earth-shattering, and the driver maintainer can always re-write it using the GPL'd code as a guideline.
-- Joe
Yes, Linus is against binary-only modules. He also states that he will not put a mechanism in place to make it easier for programmers of binary-only modules.
But, the kernel is released under the GPL, he can't stop you from writing an ABI that allows you to do this. So, while he doesn't want do the work for you, he gives you the freedom to do it if you wish. I don't see how he's inconsistent with the principles of free software. He just doesn't want to do it, nor does he have to.
If jane_hacker can't roll her own kernel, that's not Linus' problem. He gives you the kernel, what you want or are able to do with it is your problem, not his.
Maybe if you offered Linus (or somebody else with the skills) some money to write code that creates a standard ABI to make binary-only modules work, some work would be done on it.
As a final note, Linus started the kernel, it's only fair that he should be in control. If you don't like his level of control, then the GPL gives you the freedom to fork off the code and do with it as you will, as long as you release the source to the changes.
-- Joe
Yes, they make that claim. However, I have tried some programs in the past that did not work, because they used fastloaders.
The Commodore drives have five wires on the serial port (I think). Of those, I think only two of them could send data. One was the DATA line, the other the CLK line.
So, when the C64 was reading a file from the 1541, it would receive the bits one at a time over DATA, and use CLK to synchronize. This of course, was extremely slow, so somebody came up with a solution: send data over both lines, but make sure that the code on both sides was running at almost exactly the same speed.
So, the drive would break down the byte into bits, and send two bits at a time (when using the fastloader). The C64 would receive the two bits and reassemble them into the byte. But, since the CLK line was being used for data, the timing had to be precise, otherwise you'd miss bits.
So, the emulator has to emulate the drive and the C64 with 100% compatibility, or else it just won't work. Also, because sprites would mess up the CPU cycles, they had to be disabled, as did any funky IRQs (which normally there weren't any running), or you'd have problems with the data. Most fastloaders just blanked the screen, which took care of this.
-- Joe
Actually, the autoloading was usually done by machine language programs. The typical way to do it would be to write a small stub program in machine language that loaded into memory space near the I/O vectors (the cassette buffer and a small little area at $02A7 were favorites). As part of that program you would actually save a copy of the vectors, and set the load address of your executable to be that of the vectors.
When your program loaded, you overwrote the vectors, and one of them controlled where program execution went after a load.
It's been a long time since I've done that, so the exact details in my mind are hazy. But that's how some of the simple autoloaders were done.
-- Joe
I haven't done this yet, but I would imagine that you could create .D64 files (disk images), and use them.
However, it's hard to say whether or not this would work with an emulator or not. GEOS used fast-disk routines that ran in the drive memory of the 1541/1571/1581 drives, and if the emulator can't emulate the CPU in the drive (6502 in the 1541) and the 6510 in the C64 with 100% cycle exactness, then you'll have some problems.
-- Joe
You're correct on the ",8" part.
As for the ",1", well, it went like this. The first two bytes of every standard file that was designed to be loaded using kernel routines (whether it be from the BASIC LOAD command, or through the actual kernel routines) were the load address. Most basic programs were loaded into memory at $0801, so those two bytes (actually $01, $08) were at the beginning. If it was assembly code that loaded into memory at $C000, then the first two bytes were $00, $C0.
Anyway, to make a long story short, that ",1" told the load routines to load the file into the memory space pointed to by those first two bytes. Otherwise, they would be ignored, and the program would be loaded into memory at the start of BASIC memory (by default, $0801, but I think memory locations 43 and 44 changed that).
-- Joe
GEOS worked well if you had the hardware.
My setup was a Commodore 64C, two 1541 disk drives (one 1541, and one 1541-II), and a 1764 RAM Expansion Unit (256K). I used a program called Maverick (which included a utility called geoBoot I think) that would allow me to make custom boot disks for GEOS - once the GEOS kernel initialized, Maverick would interrupt it, and dump it out to floppy, thus making a 30KB or so program to run.
Those were the days... I learned some of the GUI programming concepts that I use today in writing a Desk Accessory (a word counting program for geoWrite). I loved the environment of geoProgrammer, although using geoWrite for a source code editor was a bit painful (but, with the REU, it wasn't so bad).
Hmmm, I wonder if this would work under VICE? The GEOS fast-disk routines were very timing specific, so it might not. Maybe I'll give it a try.
-- Joe
The problem is not necessarily that there's too much code, but that their code is a patch to a patch to a patch to a hack to a patch. (I'm quite familiar with this, some of the source code for the product I work on is like that too. It does get to the point where I just rewrite a module.)
It's like bolting on a new piece of metal to bridge when a hole comes in or something. Rather than replace an entire beam, they just keep patching the holes.
What Microsoft needs to do is replace areas that have too many bugs. It won't happen though because there's too many applications out there that might break (some applications "know" or "detect" the bugs and work around them), and that would be bad.
-- Joe
DOCSIS 1.1 and 2.0 do address some security concerns (like tricking the cable modem into grabbing a config file from the Ethernet port instead of the cable port), but if I understand the article (and the website of TCNISO), they have access to the serial port. Once you can issue commands at the vxWorks shell, you can pretty much figure out how to get around the security checks.
Oh, and yes, DOCSIS 1.1 and 2.0 *allow* firmware to be signed by the cable company (or by the cable modem vendor), but, the operator has to specifically enforce this, it's not automatic. And I've received requests from cable operators for unsigned firmware for DOCSIS 1.1 modems. Just like the MD5 that everybody talkes about - yes, the config files are verified with an HMAC-MD5 hash, but if the operator doesn't put in a good "shared secret" for the hash, then you have no security.
-- Joe
Here's the catch. The cable operators don't want you seeing the power level and the SNR (or your caps for that matter). Not everybody out there knows what these numbers mean (hint: SNR as high as possible, power level between 0 and 48, give or take, around 30 is good, I don't remember the numbers on the negative side). If you get two people who don't know what these numbers mean, they'll compare numbers, and suddenly the cable operators are flooded with calls like, "Hey, John's SNR is higher than mine, fix it now!". It's an added support burden on them, and they can't always fix the problem (many times, it's an issue with the coax wiring in your house).
CableLabs also has a list of parameters that aren't supposed to be viewable by customers, I don't remember off hand everything in that list (I know that the IP address of the modem is definitely one of them, I don't know about power level and SNR).
The problem with showing end-users the caps is that even though you may be capped at say, 1Mbps downstream, you might not be able to pull that in when everybody in your neighborhood is using their cable modem. Again, somebody might call in and ask why their measurement tool of choice isn't showing 1Mbps and demand it be fixed.
As for SNMP... Well, currently, SNMPv1 and SNMPv2c are used in cable networks, which is very insecure. Some operators might be using SNMPv3, but I haven't heard of anybody using it. SNMP security on modems is very weak, you can look at RFC2669 for some info as to what modems support for SNMP. The basic goal, unless you're using SNMPv3 is to setup groups of subnets and community strings that give read, write or read/write privlidges. All uncncrypted. Very weak security, really.
-- Joe
If they find a customer who they think has uncapped their modem, have the support staff set their NAC (Network Access Control) in the config file to 0 (03 01 00). The modem won't be able to pass traffic from the machine(s) behind it, and the customer will surely call you to find out why they can't get online. This assumes that they're still pulling down a config file from you, if your tech team has the "shared secret" enabled, it should be virtually impossible for them to create/edit the config file themselves (because then the HMAC-MD5 digest won't be correct).
You can then talk to the customer in more detail to see what's going on.
-- Joe
I'm still monitoring this story for interesting responses. I work in the cable industry, so this is big news for me and the company that I work for.
Anyway, a lot of the equipment in the field is older, and at the moment, I don't know of any cable modem, or CMTS chipsets that actually provide hardware encryption capabilities, therefore it's done in software. BTW, the data is encrypted only between the cable modem and the headend (CMTS), therefore all the encryption protects you from is somebody setting up a CATV sniffer somewhere between your house and the cable plant. Since that equipment is relatively expensive (last I checked, $30K), your chances of being sniffed are pretty slim, unless as you said, Joehacker turns his cable modem into an RF sniffer (definitely possible).
The encryption (BPI/BPI+), while doing encryption, also performs a more important function (especially BPI+) - they give the cable operator an element of trust, in other words, if you say that you have the "Foo XYZ" cable modem hooked up to their network, they can tell by the crypto info that you in fact do have that modem hooked up (or they can tell that you have "Bar ABC" hooked up. This is somewhat important to them, so that they can keep the "bad element" out of their networks.
BTW, the encryption isn't the only thing done in software. Like I said earlier, a lot of the equipment in the field is pretty old, so concatenation (which does what it's name implies, it concatenates packets before sending them upstream), while done in hardware on most Broadcom-based modems, is done in software on most CMTS'. This slows things down a bit as well (but the numbers show that concatenation really does improve performance, i.e. from 200 to 1000+ packets per second, 64 byte packets), so they use it heavily, despite the slower processing.
Comcast is doing quite well on the speed issue. I was previously provisioned to 1.8Mbps down, 256Kbps up, and I believe that I was recently changed to 3Mbps down/256Kbps up. I'm getting much better downstream speeds than I ever got from DSL.
-- Joe
I'm currently writing a wxWindows app under FreeBSD, but it compiles cleanly under MinGW (for Windows) as well. I haven't really had any problems up until now.
I'm curious to know what problems you had with it so that I can try to avoid them.
-- Joe
The TCNISO website mentions three Motorola Surfboard modems that this works with, the SB3100, the SB4100 and the SB4200. I guaran-damn-tee that these modems are all DOCSIS certified (Motorola advertises them as such, and cannot do so without CableLabs' permission, or else they could face some legal issues). The SB3100 is DOCSIS 1.0 certified (upgradable to 1.1), and the SB4100 and SB4200 are DOCSIS 1.0 and 1.1 certified. (I also verified their certification status with my contacts.) Certified DOCSIS modems have a green sticker on them with the letters "CL", and state "CableLabs Certified" (or use this in their marketing literature, or on the box).
A mistake that I made in the previous post - if the revocation takes effect, it will only pose a problem on operators running BPI+ (which they should do with DOCSIS 1.1). An operator running BPI (if I recall correctly, I may be wrong, I don't know the DOCSIS spec by heart) can't use the revocation list, since BPI only uses public/private key pairs, not exact X.509 certificates (note that operators can ban modems based on other methods than certificates, like MAC address). Nonetheless, if Motorola used the same CA to generate certificates for all their modems (a good possibility), a revocation of that CA means that all modems signed with that CA are useless in a BPI+ environment.
Most operators are still running DOCSIS 1.0, with or without BPI (note the "no comment" from many cable operators in the article), but many of them are planning to switch to DOCSIS 1.1 with BPI+ in order to take advantage of the extra functionality and security.
Disclaimer: Again, all of what I have stated is basically publically available knowledge.
-- Joe
I won't comment on the legality of this, because I'm not a lawyer. I don't know if it's legal or not.
It's quite possible that it would be a decent vxWorks development platform. WindRiver uses patched version of GCC (the patches mainly apply to specific variants of the processors), and I personally find the GUI project maker of Tornado (the client side tools of vxWorks) to be absolutely awful. Makefiles work much better.
However, in order to actually compile applications, you'll need the static vxWorks libraries, you'd have to figure out a way to extract them from the cable modem binary (I don't know anything about Motorola's firmware file format, so I don't know if you can do this or not) in order to link, short of buying the development environment.
So, it might help you learn some stuff about the vxWorks shell, but maybe not much else.
-- Joe