I never said cable networks are capable of giving each customer a dedicated pipe. In the end, the total bandwidth of the fiber run is shared with all devices passing traffic through it. Whether a few strands have been spliced off to feed a single customer is irrelevant, though that is highly unlikely.
However, that doesn't mean that if I hack my modem to bridge all traffic that I'll be able to see the outbound traffic of my friend that lives across town. That doesn't even mean that I'll be able to see his inbound traffic. (That last one depends a lot on the switching infrastructure put in place.)
And no, I'm not confusing the layers. When I said packet shaping is at the network layer, I meant it. Yes, if the customer had 10 IPs, they could have 10 times the bandwidth. That is what you want. That way if they have 10 computers, and are paying for 10 IPs, each computer gets exactly how much it is supposed to have. Don't mix packet shaping in with preventing unauthorized IPs. They are different problems with different solutions. They do, however, work together quite well.
If they are only paying for one IP, you can prevent them from dhcp leasing extras by watching the ethernet MACs of the lease requests. Add to this the UBR's ability to limit the number of IPs that bridge based on DCE id (cable modem serial number or MAC id), and you have an effective way of preventing anyone from using more resources than they are supposed to have.
Trust me, there are ways of keeping users from hogging all the resources, and they aren't that difficult to implement. The main problem is that most cable companies don't bother to build an effective infrastructure, simply because they are used to the CATV way of doing things. (Add filter to lines that don't get HBO. If filter is found to be removed, put a new one back on. If filter is continually removed, file criminal case for theft of service.) (The inverse of that is sometimes true as well. Many systems will introduce noise in the signal at the headend, and then filter it out at the customer location, so only those that have filters will get the service.)
Anyhow, please don't confuse CATV over fiber networks, and data over fiber networks. They are different animals that play in the same meadow. Beyond that similiarity, nothing else can really be assumed at the link layer. For instance: Have you ever tried taking your cable modem across town, and plugging it in to someone elses cable line, even if they are paying for cable modem service? Depending on the switching infrastructure, it probably won't work. Outbound packets can be addressed by either OTN or node (i forget which), and are squelched on the lines that do not service that destination. CATV is a different signal, destined for all addresses. Thus, it is never squelched.
I hate to break it to you, but you are dead wrong about the one-to-many network style. That may work for television, where the communication is only one way, but for IP to work there must be a network wide unique IP at each customer location. (And I haven't seen a Cable provider yet that doesn't give you a world routable IP, rather than an IP from the private IP blocks.) And on top of that, the technology to provide bi-directional cable (for modems and even set-top boxes that don't need to dial in) does indeed require packet switching, much like the phone company's lines. I've been in the cable business myself for years, I know the hardware pretty well. Regardless of any of this, packet shaping is done at the network layer (ie by IP address), not the physical or data link layer.
So there is no reason at all why those buffoons could not have installed a packet shaper to manage their traffic. None. The problem is that they have the cable company mentality. Where they immediately prosecute anyone who steals service, rather than taking measures to prevent such theft in the first place.
Yes, they have a legal right to prosecute theft of service, but you can't tell me that they wouldn't save money by simply packet shaping, rather than paying for lawyers and court fees.
This is rediculous. FBI knocks down your door because your cable provider is too stupid to properly keep its customers from sucking up all the bandwidth?
What happens when the system is DOCSIS compliant, and the modem you are using is YOURS. Then what? Arrest you because you made an aftermarket modification to your own property?
This is a fucking joke. The solution isn't to arrest the people that uncap their modems. The solution is to install a packet shaper to manage bandwidth usage from a location inaccessible to your customers. Once again, cable companies prove that they are not capable of being competent ISPs.
What I'd like to see is a federal law passed that requires cable companies to share their lines with local competitors, much like the phone companies. I think we'd see a lot less of this crap once we had cable modem providers that did not have a CATV service on the side, or any CATV mentality....fucking morons
More exciting is conformance to a single ABI standard in combination with installation script support. This is a godsend for package maintainers; in the future they will only have to compile and package once, and your app is supported on multiple distros.
Isn't that what United Linux was all about? LSB compliance, plus a standard filesystem layout, plus a standard set of libraries, plus standardized international language support.
Forgive me, but I feel that United Linux was on the right track. The only problem with it was that Ransom Love's name was on the list of founders. Well, that and the obvious fact that it is pretty much still vaporware at this point.
Still, it seems sad that a good idea gets the shit treatment simply because people have a bad attitude about one of its supporters.
I completely agree with you in that there are actually plenty of very workable solutions to privacy concerns. Triangle boy; encrypted tunnels to outside proxies; RAM disk style Linux boxes that boot and load into RAM disk off a CDROM, set up to auto reboot immediately after log off.
Like many people have already said, some libraries already throw away information on items checked out once they are checked back in. So accountability only lasts as long as you have the item.
So privacy of what you check out isn't really a big problem to solve. The biggest problem are the computers they keep for public use. There are plenty of ways to solve this, but I don't see any of them using Windows. Which pretty much makes them useless to libraries, since Windows is exactly what the public wants. Maybe you could put up a single "secure" machine that ran Linux off a RAM disk and performed the autoreboot I mentioned earlier. But I highly doubt we'll ever see a library with no public MS machines in the next 10 years.
Anyhow, nice chattin with ya. Hope I didn't stir up any hatred.:)
Alright, I was hoping that maybe I could get some intelligent replies, but apparently not. I guess you really do need to spell it out for some people. (BTW, don't get the idea that this is entirely a direct attack on the parent's author. This is just the thread on which I clicked 'reply to this'.
I'll start out with the issue of an OS not fitting into RAM. I don't know about your area, but in my area the libraries could give less of a shit about linux on their public access PCs. Realistically, the PCs aren't there in order to show the world that linux is a great solution for everyday problems, the PCs are there to provide a simple service. Word processing and internet access. PERIOD. There is a reason why those boxes are Wintel machines. Mainly because it is what 90% of the desktop computer using population is familiar with. Yes, linux would solve this problem quite nicely, but I can guarantee you that any proposal suggesting the use of linux would get a lot of "what the hell is leenux?" going on in the background, following by some light chuckling. When people go to the library to use the computers, they expect to use MS office, and surf the net. Sorry, but that is the extent of it. Yes, there is openoffice, and I agree that mozilla kicks the shit out of IE. But the fact remains, OpenOffice isn't MS Office, and mozilla is still plagued by plenty of IE only websites.
Now for a few direct rebuttals: No where did I ever mention that an FBI agent would gain access to data on powered down RAM. The IQ reference was in regards to them shutting the machine off to begin with. Like I said, they aren't fucking idiots. If they lose the logs once to a RAM disk, you can bet they won't make that mistake again. Next time they'll simply leave it on, or as I said, tap the network at the ISP.
And I don't know where you got the idea that I was referring to book checkout logs when I was talking about tapping at the ISP. I would sure as hell hope that any library with half a mind wouldn't use a public network to service their internal database transactions. However, even if the logs were the target of the search, they could just simply walk up to the machine hosting the database and fuss all they wanted to while the librarians called their bosses to explain how the FBI just walked in with a search warrant. And if you've read my previous post, you'll remember that you can't have both accountability and anonymity. The two are mututually exclusive. No amount of fancy encryption is ever going to change that. Please think before you flame. I don't post crap, so I don't expect crap in return.
You must have some pretty good crack in your pipe today. Anonymous Checkout? Sure! I'll just anonymously check out a few expensive books I've always wanted, and just keep them. Since it's anonymous, they'll never know who has them, so they can't bill me for them or come looking for them. The only way you're going to keep theft out of the equation is to keep tabs on who has what, but throw away that data the minute the book is returned. No amount of encryption is ever going to make anonymous checkouts work, since you must always be able to tell who has what.
As for running your entire OS in a ramdisk...yea...sure...that's...great. I don't know about you, but I sure as hell wouldn't pass any mileage that simply wanted to put 3GB of ram in every public computer. All so that the entire OS can run in a RAM disk so that we can have a false sense of anonymity on those machines. If the FBI wants to see where a computer has been, they will find out. Yes, if they turn off the machine, everything is lost. But this will only get them once or twice. They aren't fucking idiots. They will catch on, and start going to the library's isp instead and plugging a nifty little black box between the library and the internet. "Wow, look! I can see every packet going in or out of that building. How nice!"
Where did you ever hear that? Seriously, Tesla coils really were always about arcing electricity. His original idea for Tesla coil usage was wireless transportation of electricity. Basically, if you crank the volts enough, you can arc across the atlantic ocean. At least that was the idea.
Yes, Tesla also did some studies on structural harmonics. And yes, he did the structural harmonics work long before he came up with the idea for Tesla coils, but aside from being the brainchild of the same man, the two were never linked in any other way.
Also, I must say that I more enjoyed his work on structural harmonics. Shaking bridges and collapsing condemned buildings was all well and good, but the nutball had the idea that he could crack the earth in half if he used enough dynamite and timed it correctly. Good thing he didn't have the resources to try that one out. Tesla was crazy enough try it, just to see if it would work.
I vote GnuCash. Seriously. All of the pretty graphs and predictions built into Quicken are great, but it is all absolutely useless when the data entry tools are borked. GnuCash uses a double entry system, which is far more sane than any single entry system I've every seen. (More resistant to typos as well.) And I can't believe that Quicken STILL doesn't have any way to tell you what your CLEARED balance is in your checking accounts. GnuCash has had this ever since I can remember, but I'll be damned if I can find a way to look at it in Quicken. Sure, the column is there, but other than the satisfaction of seeing a little "c" in the column for every transaction, I see no use for it in Quicken. My wife and I each keep track of our own accounts, and I'm consistantly able to tell you down to the penny how much money I have. And she is consistantly able to screw up her registers in Quicken because she can't see what her cleared balance is when she's comparing between Quicken and her online statements.
Like I said, GnuCash has the cleared balance neatly displayed at the top of the register at all times. It makes keeping your bank register and your finance software in sync much easier. But hey, I (and my wife) may just be unable to use Quicken properly. Which I must admit is odd, considering how easy GnuCash is for me to use on a daily basis. Plus, the learning curve was basically nil. I was up and running full time in less than 4 hours, and I have almost no experience tracking my finances this closely. (I used to just make sure I had a few thousand bucks in my account at all times, and then I could be pretty sure I wasn't going to over withdraw it.)
Kudos to the GnuCash team. My only complaint is that I can't download generic precompiled binaries off their website that will run on nearly all linux distros. But then again, that's not entirely their fault, considering how fucked up Linux gets in the cross distro compatibility area...
Anyhow, long story short. By my vote: GnuCash == good. Quicken == garbage.
You know, it's good to see that SGI hasn't entirely lost their grasp on what had initially built their empire. Every since I had first heard of SGI, their name has basically stood for graphics power beyond belief. Then suddenly they lost their edge. No one needed SGI's for mechanical engineering anymore, since the processor speed in IBM clones had caught up, and consumer grade video cards designed initially to run games could perform quite well with most CAD related tasks. In fact, cards designed for games, at one point, seemed to even be outperforming all of SGI's offerings.
Combine that with SGI's sudden idea to start selling x86 systems running linux, and I was sure that they were only a year or two away from closing shop.
It's good to see them finally getting back to what they were always good at. Making video cards that performed admiringly well when given tasks that would bring the competition to it's knees, and putting together the systems with the custom busses required to push these cards.
Anyways, enough of "yay SGI".
It's also nice to see Sun finally getting in on the high level gfx market as well. I've always favored Sun when it came to selecting Unix servers. It's nice to see that they have an offering for the gfx market as well.
Is everybody still inventing his own application layer protocol?
By definition, the application layer protocol is built into the application. I think you meant to say, "is everybody still foregoing the use of a presentation layer to make the application layer do less work"
Sounds a bit like my project LInstaller. Except I'm going the C route instead of bash script. I decided to use GTK+ 2.0 as the GUI side of the installer, but I'm currently rethinking that decision. The main problem I'm having is shared object filenames. Most distros are fairly similar, but I'll be damned if 90% of the libraries on any system don't have their "soname" field properly filled in. Hence compiling any application against them will produce binaries that insist on an exact version, rather than any version of the same major version.
I suppose I could try to find an ELF header editor, so I could manually change the program dependancies to the correct values.
On a side note, Mandrake didn't seem to provide libXft like Redhat does. Apparently Mandrake decided on their own Xft'less way. *shrug* Doesn't matter now, I've already switched back to developing on a Redhat system.
Re:Problem not entirely RPM's fault
on
Is RPM Doomed?
·
· Score: 2
Neither of which are complete enough to allow for binary compatability, and don't even touch on file system layout.
Problem not entirely RPM's fault
on
Is RPM Doomed?
·
· Score: 3, Interesting
RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.
I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.
The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.
To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.
Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.
So turn it off. If you only use it for emergencies then you shouldn't care whether it is on or off, since you don't make or take calls on it unless there is an emergency.
There is a very distinct difference between stand-by and off. One still uses battery power, the other does not. Making the network peer to peer doesn't make your phone use power while it's shut off.
And I don't know what kind of phone you're using if it doesn't still try to check back with the tower every few seconds while in stand-by. Mine sure as hell does. Going underground all day? Then you'd better turn your phone with a "3 day stand-by" off, or else it will be flat dead in under 8 hours. A peer to peer network wouldn't cause this, as each only tries to talk to nearby phones, which in most cases would get your signal back topside within a few hops.
Realistically, I'd question the scalability. I'd SERIOUSLY question the scalability. Gnutella is peer to peer, and it doesn't scale well at all. Even with UltraPeers (peers that actually act more like routers), the network still uses a HELL of a lot of bandwidth. Even when you throw out the power consumption issue, the processing power and bandwidth issues come up.
This is a very interesting idea, though I can't say that I haven't already heard of it. Still, if they can put together 1000 units, and make it work for a week inside of a single building, I'll be impressed.
This is very true. Windows has a horrible time staying up for long periods of time. At my previous employer, we had several Linux/x86 and Irix/SGI boxes with uptimes varying between 8 months to a year and a half. The only time these boxes were ever shutdown or rebooted was for kernel upgrades and hardware upgrades/replacements.
On the otherhand, we also had several Windows boxes, and an MCSE on staff. We ended up scheduling automatic reboots every weekend in the mornings because the boxes would hang or crash if we didn't. The MCSE was no idiot either. There was literally no good reason why those boxes had to be rebooted all the time, they just did.
This seems to be the case with a lot of Multimedia applications in Linux. Xine, Mplayer, transcode... they all seem to include all their required libraries internally instead of just linking to the appropriate one already on the system. Perhaps this is a reflection on how chaotic multimedia is in Linux. The only way to get consistent libraries is to just include them directly?
That's funny. I've been saying this about Linux for the past few years. The problem you describe is entirely true, but it is much more severe. This isn't just a problem with Multimedia in Linux, this is a problem with binary compatability between distros.
The only way to ensure you get the libraries you need is to package them with your application. But, RPM is only good at packaging one thing at a time. One application, or one general library. If you try to cram both into a single RPM, you'll get funny problems when you try to install it.
For instance, I can see why they suggest rpm -i --nodeps --force package.rpm. If one of the libraries is already installed, RPM will refuse to install the entire package because it doesn't want to overwrite a file. Obviously their solution could have been better implemented (put the libs in a subdir that won't break things and L_PRELOAD them from there), but the problem really shouldn't have been an issue in the first place!
But it is, and it is because Linux has no standards. Anyone can roll their own Linux system, but that potentially breaks everything that a software vendor could ever expect to find on that system.
The fact is, we need to get a standard to cover what a Linux distro must have to be considered a usable system. The LSB has about zero steam on its own. Its best shot is UnitedLinux, but of course everyone wants to instantly condemn UL because of what they thought they heard someone think they believed last tuesday under a full moon.
All I can say is, I hope UL make it through long enough to at least establish some consistency between the involved distros, and that people notice how useful that really is before it is too late...
I'm not the only one who sees this.
They provide broadband over the air. It's simply DOCSIS piped over the airwaves. The bonus is that these guys are actually using FCC regulated space, so they won't have cordless phones and microwave ovens interfering with their service. These guys are able to transmit 30 miles, and their installation is up and running in two locations right now.
Someone Mod this parent up! Someone is finally talking with some sense, instead of waving their arms and shouting without reading any of the facts. Again, mod the parent up!
Actually, Shawn Fanning could still get rich. He just needs to write a book about the rise and fall of Napster. Give it a catchy title and make sure it doesn't sound like 3 years olds ramblings that should have been scrawled out in crayon, and he'd probably sell a few hundred thousand copies.
You know, I could care less if there are 5 or 5000 Linux distributions out there. But I'm really getting tired of the lack of binary compatability between distributions. And when I say that, I mean lack of binary compatability all the way from libc up to the desktop environment. I can compile simple command line apps and have it run on most distributions, but the second I start using extra libraries (like GTK+) I start running into compatability problems between distros.
Distro A has the library, but it's a different filename since it's a newer version than the one in Distro B. Bah! The best tech that MS stole was COM objects. Just cram all the necessary versions into a single file, and let the runtime linker figure it out on the fly.
Well, I'm not trying to say that we need that sort of extra functionality/overhead, but I do want to say that Linux will take off like a shot at soon as developers have a steady target to aim for. The sooner all the major distros decide on a list of libraries that make up a standard linux distribution, the sooner I'll be able to start telling my friends and family that they should switch.
RPM, apt, deb, and even slack's TGZ all have the same problem. The application/library is compiled and packaged for a single version of a single distribution. Sometimes you can take them to another version or distro and it will work, but most often not. With a little fussing, you can usually put together some symlinks on a few libs that will at least get the app to run, but certain features won't work correctly, or the app will crash because a certain interface isn't exposed by this version of a lib. Even if it did run 100% correctly after you made the necessary symlinks, that still isn't good enough, since you had to manually manipulate the system in order to get the app to run. I don't tell my family to run regedit when they can't get an item out of the "Uninstall Application" menu (I fix it for them next time I'm over there), so I'm not going to tell them to "Just make a few symlinks in/usr/lib and you'll be okay" either!
Man this continual problem pisses me off... It's so basic that I was sure that it would have been worked out by now. I've looked and looked and found nothing. The Linux Standard Base doesn't even come close to defining everything that is necessary for binary compatability between distros, and google hasn't given me any other good leads.
If I'm missing the big red neon sign that points to the solution, then please do share it with me. But if I simply haven't found it because it doesn't exist, then we should defenitely evaluate the value that this would add to Linux, and seriously consider its immediate implementation.
You must not be very familiar with Solaris at all. Solaris is anything but "fast and stable". XSun is horribly lathargic, and Solaris is known to have core libraries that leak memory (which is why Apache allows you to set the maximum requests serviced per forked child).
As for Sun making great hardware, that is more bunk. The SPARC architecture is an open standard. Anyone who actually uses these things knows that there are several different manufacturers that you can go to for processors and equipment.
What Sun does well is selling their name, and R&D. Sun has been the first to come out with exciting new technologies on several occasions. They aren't always implemented in the best way, and sometimes they aren't even realistically useful tech, but they do put the man hours into it, which is quite commendable (especially when everyone is still whining about the economy).
I'll agree with you about CDE though, it vigorously sucks donkey balls through a garden hose like a french whore on speed.
I have to whole heartedly agree with you on this. The US government is, and never was, charged with the responsibility to ensure that a business model that made money in the past is able to make money in the future.
If they were, we'd still see horse drawn buggies, since they auto would have been banned. It cuts into buggy sales, and we can't have that.
Or, if you want to allow products to be replaced (ie tapes were replaced by CDs, so buggies can be replaced by cars) but not allow business models that feed off of others, then I have another argument. How do you explain taxi services and forms of public transportation? You can't tell me that these don't cut into auto sales. Why have a car when you live and work in downtown Chicago? Or even take a bike.
The government endorses public transportation, but it shuns public music distribution channels? What the fuck is up with that?
All I can say, is I'm getting sick of these government officials being on the side of large businesses simply because they are large campaign contributers. I have a nice new law for you. If you accept money from a corporation or individual, you may not vote on any issues directly relating to that corporation or individual's well being. In other words, if the RIAA 'donates' $100k toward your campaign, and you accept it, you aren't allowed to vote on any bill, or push any legislation, that has to do with digital rights management, music copyright, or anything else the RIAA gets their fingers into. I guess you better stick to water purification and eco-system issues.
"Until you have a positive assertion of what consumers' rights are, that debate is left in the hands of media companies' lawyers," said Mr. Krauss, who founded Excite, the now-defunct on-line portal.
Excuse me, but last time I checked, my rights were inalienable and included everything that I didn't willingly give up for the good of society. It has nothing to do with what lawyers have deemed acceptable for me to have. If your business sense is as acute as your legal sense, it's no wonder your portal is now "defunct".
I'm sick of seeing companies changing the price model for bandwidth. Once you have an OC-192, what the hell does it matter if you fill it, or not. You're already paying for the whole damn thing, whether it is full or not. Some people will use the network like mad, and some won't. That's how it works. Not to mention, that's why we pay for your fucking service.
I may download 18 full 650MB isos one month, and the next month I spend all of my time writing code and checking my email. That's the way it is supposed to work. What one guy doesn't use, the other will.
Besides, if you're tired of your users filling up your OC-192 24 hours a day with peer to peer filesharing apps, why don't you try doing something truly innovative. Start your own server to act as a proxy, and firewall the users from actually passing through your router. Now you've just removed all of the pointless "I'm still here" packets, and only left the data transfer packets. What's better, your network users can share all they want over your internal network, and it won't cost you a dime in additional internet bandwidth. What a fucking idea!
Sorry for being such a prick about this, but I've had my fill of clueless network admins who insist on fighting what their users really want.
Slashdot Mirror
I never said cable networks are capable of giving each customer a dedicated pipe. In the end, the total bandwidth of the fiber run is shared with all devices passing traffic through it. Whether a few strands have been spliced off to feed a single customer is irrelevant, though that is highly unlikely.
However, that doesn't mean that if I hack my modem to bridge all traffic that I'll be able to see the outbound traffic of my friend that lives across town. That doesn't even mean that I'll be able to see his inbound traffic. (That last one depends a lot on the switching infrastructure put in place.)
And no, I'm not confusing the layers. When I said packet shaping is at the network layer, I meant it. Yes, if the customer had 10 IPs, they could have 10 times the bandwidth. That is what you want. That way if they have 10 computers, and are paying for 10 IPs, each computer gets exactly how much it is supposed to have. Don't mix packet shaping in with preventing unauthorized IPs. They are different problems with different solutions. They do, however, work together quite well.
If they are only paying for one IP, you can prevent them from dhcp leasing extras by watching the ethernet MACs of the lease requests. Add to this the UBR's ability to limit the number of IPs that bridge based on DCE id (cable modem serial number or MAC id), and you have an effective way of preventing anyone from using more resources than they are supposed to have.
Trust me, there are ways of keeping users from hogging all the resources, and they aren't that difficult to implement. The main problem is that most cable companies don't bother to build an effective infrastructure, simply because they are used to the CATV way of doing things. (Add filter to lines that don't get HBO. If filter is found to be removed, put a new one back on. If filter is continually removed, file criminal case for theft of service.) (The inverse of that is sometimes true as well. Many systems will introduce noise in the signal at the headend, and then filter it out at the customer location, so only those that have filters will get the service.)
Anyhow, please don't confuse CATV over fiber networks, and data over fiber networks. They are different animals that play in the same meadow. Beyond that similiarity, nothing else can really be assumed at the link layer. For instance: Have you ever tried taking your cable modem across town, and plugging it in to someone elses cable line, even if they are paying for cable modem service? Depending on the switching infrastructure, it probably won't work. Outbound packets can be addressed by either OTN or node (i forget which), and are squelched on the lines that do not service that destination. CATV is a different signal, destined for all addresses. Thus, it is never squelched.
Anyways, was fun chatting with ya!
Cheers!
I hate to break it to you, but you are dead wrong about the one-to-many network style. That may work for television, where the communication is only one way, but for IP to work there must be a network wide unique IP at each customer location. (And I haven't seen a Cable provider yet that doesn't give you a world routable IP, rather than an IP from the private IP blocks.) And on top of that, the technology to provide bi-directional cable (for modems and even set-top boxes that don't need to dial in) does indeed require packet switching, much like the phone company's lines. I've been in the cable business myself for years, I know the hardware pretty well. Regardless of any of this, packet shaping is done at the network layer (ie by IP address), not the physical or data link layer.
So there is no reason at all why those buffoons could not have installed a packet shaper to manage their traffic. None. The problem is that they have the cable company mentality. Where they immediately prosecute anyone who steals service, rather than taking measures to prevent such theft in the first place.
Yes, they have a legal right to prosecute theft of service, but you can't tell me that they wouldn't save money by simply packet shaping, rather than paying for lawyers and court fees.
This is rediculous. FBI knocks down your door because your cable provider is too stupid to properly keep its customers from sucking up all the bandwidth?
...fucking morons
What happens when the system is DOCSIS compliant, and the modem you are using is YOURS. Then what? Arrest you because you made an aftermarket modification to your own property?
This is a fucking joke. The solution isn't to arrest the people that uncap their modems. The solution is to install a packet shaper to manage bandwidth usage from a location inaccessible to your customers. Once again, cable companies prove that they are not capable of being competent ISPs.
What I'd like to see is a federal law passed that requires cable companies to share their lines with local competitors, much like the phone companies. I think we'd see a lot less of this crap once we had cable modem providers that did not have a CATV service on the side, or any CATV mentality.
Forgive me, but I feel that United Linux was on the right track. The only problem with it was that Ransom Love's name was on the list of founders. Well, that and the obvious fact that it is pretty much still vaporware at this point.
Still, it seems sad that a good idea gets the shit treatment simply because people have a bad attitude about one of its supporters.
I completely agree with you in that there are actually plenty of very workable solutions to privacy concerns. Triangle boy; encrypted tunnels to outside proxies; RAM disk style Linux boxes that boot and load into RAM disk off a CDROM, set up to auto reboot immediately after log off.
:)
Like many people have already said, some libraries already throw away information on items checked out once they are checked back in. So accountability only lasts as long as you have the item.
So privacy of what you check out isn't really a big problem to solve. The biggest problem are the computers they keep for public use. There are plenty of ways to solve this, but I don't see any of them using Windows. Which pretty much makes them useless to libraries, since Windows is exactly what the public wants. Maybe you could put up a single "secure" machine that ran Linux off a RAM disk and performed the autoreboot I mentioned earlier. But I highly doubt we'll ever see a library with no public MS machines in the next 10 years.
Anyhow, nice chattin with ya. Hope I didn't stir up any hatred.
Alright, I was hoping that maybe I could get some intelligent replies, but apparently not. I guess you really do need to spell it out for some people. (BTW, don't get the idea that this is entirely a direct attack on the parent's author. This is just the thread on which I clicked 'reply to this'.
I'll start out with the issue of an OS not fitting into RAM. I don't know about your area, but in my area the libraries could give less of a shit about linux on their public access PCs. Realistically, the PCs aren't there in order to show the world that linux is a great solution for everyday problems, the PCs are there to provide a simple service. Word processing and internet access. PERIOD. There is a reason why those boxes are Wintel machines. Mainly because it is what 90% of the desktop computer using population is familiar with. Yes, linux would solve this problem quite nicely, but I can guarantee you that any proposal suggesting the use of linux would get a lot of "what the hell is leenux?" going on in the background, following by some light chuckling. When people go to the library to use the computers, they expect to use MS office, and surf the net. Sorry, but that is the extent of it. Yes, there is openoffice, and I agree that mozilla kicks the shit out of IE. But the fact remains, OpenOffice isn't MS Office, and mozilla is still plagued by plenty of IE only websites.
Now for a few direct rebuttals:
No where did I ever mention that an FBI agent would gain access to data on powered down RAM. The IQ reference was in regards to them shutting the machine off to begin with. Like I said, they aren't fucking idiots. If they lose the logs once to a RAM disk, you can bet they won't make that mistake again. Next time they'll simply leave it on, or as I said, tap the network at the ISP.
And I don't know where you got the idea that I was referring to book checkout logs when I was talking about tapping at the ISP. I would sure as hell hope that any library with half a mind wouldn't use a public network to service their internal database transactions. However, even if the logs were the target of the search, they could just simply walk up to the machine hosting the database and fuss all they wanted to while the librarians called their bosses to explain how the FBI just walked in with a search warrant. And if you've read my previous post, you'll remember that you can't have both accountability and anonymity. The two are mututually exclusive. No amount of fancy encryption is ever going to change that. Please think before you flame. I don't post crap, so I don't expect crap in return.
You must have some pretty good crack in your pipe today. Anonymous Checkout? Sure! I'll just anonymously check out a few expensive books I've always wanted, and just keep them. Since it's anonymous, they'll never know who has them, so they can't bill me for them or come looking for them. The only way you're going to keep theft out of the equation is to keep tabs on who has what, but throw away that data the minute the book is returned. No amount of encryption is ever going to make anonymous checkouts work, since you must always be able to tell who has what.
As for running your entire OS in a ramdisk...yea...sure...that's...great. I don't know about you, but I sure as hell wouldn't pass any mileage that simply wanted to put 3GB of ram in every public computer. All so that the entire OS can run in a RAM disk so that we can have a false sense of anonymity on those machines. If the FBI wants to see where a computer has been, they will find out. Yes, if they turn off the machine, everything is lost. But this will only get them once or twice. They aren't fucking idiots. They will catch on, and start going to the library's isp instead and plugging a nifty little black box between the library and the internet. "Wow, look! I can see every packet going in or out of that building. How nice!"
Three words: Waste of money.
Where did you ever hear that?
Seriously, Tesla coils really were always about arcing electricity. His original idea for Tesla coil usage was wireless transportation of electricity. Basically, if you crank the volts enough, you can arc across the atlantic ocean. At least that was the idea.
Yes, Tesla also did some studies on structural harmonics. And yes, he did the structural harmonics work long before he came up with the idea for Tesla coils, but aside from being the brainchild of the same man, the two were never linked in any other way.
Also, I must say that I more enjoyed his work on structural harmonics. Shaking bridges and collapsing condemned buildings was all well and good, but the nutball had the idea that he could crack the earth in half if he used enough dynamite and timed it correctly. Good thing he didn't have the resources to try that one out. Tesla was crazy enough try it, just to see if it would work.
I vote GnuCash. Seriously. All of the pretty graphs and predictions built into Quicken are great, but it is all absolutely useless when the data entry tools are borked. GnuCash uses a double entry system, which is far more sane than any single entry system I've every seen. (More resistant to typos as well.) And I can't believe that Quicken STILL doesn't have any way to tell you what your CLEARED balance is in your checking accounts. GnuCash has had this ever since I can remember, but I'll be damned if I can find a way to look at it in Quicken. Sure, the column is there, but other than the satisfaction of seeing a little "c" in the column for every transaction, I see no use for it in Quicken. My wife and I each keep track of our own accounts, and I'm consistantly able to tell you down to the penny how much money I have. And she is consistantly able to screw up her registers in Quicken because she can't see what her cleared balance is when she's comparing between Quicken and her online statements.
Like I said, GnuCash has the cleared balance neatly displayed at the top of the register at all times. It makes keeping your bank register and your finance software in sync much easier. But hey, I (and my wife) may just be unable to use Quicken properly. Which I must admit is odd, considering how easy GnuCash is for me to use on a daily basis. Plus, the learning curve was basically nil. I was up and running full time in less than 4 hours, and I have almost no experience tracking my finances this closely. (I used to just make sure I had a few thousand bucks in my account at all times, and then I could be pretty sure I wasn't going to over withdraw it.)
Kudos to the GnuCash team. My only complaint is that I can't download generic precompiled binaries off their website that will run on nearly all linux distros. But then again, that's not entirely their fault, considering how fucked up Linux gets in the cross distro compatibility area...
Anyhow, long story short.
By my vote: GnuCash == good. Quicken == garbage.
You know, it's good to see that SGI hasn't entirely lost their grasp on what had initially built their empire. Every since I had first heard of SGI, their name has basically stood for graphics power beyond belief. Then suddenly they lost their edge. No one needed SGI's for mechanical engineering anymore, since the processor speed in IBM clones had caught up, and consumer grade video cards designed initially to run games could perform quite well with most CAD related tasks. In fact, cards designed for games, at one point, seemed to even be outperforming all of SGI's offerings.
Combine that with SGI's sudden idea to start selling x86 systems running linux, and I was sure that they were only a year or two away from closing shop.
It's good to see them finally getting back to what they were always good at. Making video cards that performed admiringly well when given tasks that would bring the competition to it's knees, and putting together the systems with the custom busses required to push these cards.
Anyways, enough of "yay SGI".
It's also nice to see Sun finally getting in on the high level gfx market as well. I've always favored Sun when it came to selecting Unix servers. It's nice to see that they have an offering for the gfx market as well.
Sounds a bit like my project LInstaller. Except I'm going the C route instead of bash script. I decided to use GTK+ 2.0 as the GUI side of the installer, but I'm currently rethinking that decision. The main problem I'm having is shared object filenames. Most distros are fairly similar, but I'll be damned if 90% of the libraries on any system don't have their "soname" field properly filled in. Hence compiling any application against them will produce binaries that insist on an exact version, rather than any version of the same major version.
I suppose I could try to find an ELF header editor, so I could manually change the program dependancies to the correct values.
On a side note, Mandrake didn't seem to provide libXft like Redhat does. Apparently Mandrake decided on their own Xft'less way. *shrug* Doesn't matter now, I've already switched back to developing on a Redhat system.
Neither of which are complete enough to allow for binary compatability, and don't even touch on file system layout.
RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.
I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.
The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.
To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.
Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.
So turn it off. If you only use it for emergencies then you shouldn't care whether it is on or off, since you don't make or take calls on it unless there is an emergency.
There is a very distinct difference between stand-by and off. One still uses battery power, the other does not. Making the network peer to peer doesn't make your phone use power while it's shut off.
And I don't know what kind of phone you're using if it doesn't still try to check back with the tower every few seconds while in stand-by. Mine sure as hell does. Going underground all day? Then you'd better turn your phone with a "3 day stand-by" off, or else it will be flat dead in under 8 hours. A peer to peer network wouldn't cause this, as each only tries to talk to nearby phones, which in most cases would get your signal back topside within a few hops.
Realistically, I'd question the scalability. I'd SERIOUSLY question the scalability. Gnutella is peer to peer, and it doesn't scale well at all. Even with UltraPeers (peers that actually act more like routers), the network still uses a HELL of a lot of bandwidth. Even when you throw out the power consumption issue, the processing power and bandwidth issues come up.
This is a very interesting idea, though I can't say that I haven't already heard of it. Still, if they can put together 1000 units, and make it work for a week inside of a single building, I'll be impressed.
This is very true. Windows has a horrible time staying up for long periods of time. At my previous employer, we had several Linux/x86 and Irix/SGI boxes with uptimes varying between 8 months to a year and a half. The only time these boxes were ever shutdown or rebooted was for kernel upgrades and hardware upgrades/replacements.
On the otherhand, we also had several Windows boxes, and an MCSE on staff. We ended up scheduling automatic reboots every weekend in the mornings because the boxes would hang or crash if we didn't. The MCSE was no idiot either. There was literally no good reason why those boxes had to be rebooted all the time, they just did.
The only way to ensure you get the libraries you need is to package them with your application. But, RPM is only good at packaging one thing at a time. One application, or one general library. If you try to cram both into a single RPM, you'll get funny problems when you try to install it.
For instance, I can see why they suggest rpm -i --nodeps --force package.rpm. If one of the libraries is already installed, RPM will refuse to install the entire package because it doesn't want to overwrite a file. Obviously their solution could have been better implemented (put the libs in a subdir that won't break things and L_PRELOAD them from there), but the problem really shouldn't have been an issue in the first place!
But it is, and it is because Linux has no standards. Anyone can roll their own Linux system, but that potentially breaks everything that a software vendor could ever expect to find on that system.
The fact is, we need to get a standard to cover what a Linux distro must have to be considered a usable system. The LSB has about zero steam on its own. Its best shot is UnitedLinux, but of course everyone wants to instantly condemn UL because of what they thought they heard someone think they believed last tuesday under a full moon.
All I can say is, I hope UL make it through long enough to at least establish some consistency between the involved distros, and that people notice how useful that really is before it is too late... I'm not the only one who sees this.
They provide broadband over the air. It's simply DOCSIS piped over the airwaves. The bonus is that these guys are actually using FCC regulated space, so they won't have cordless phones and microwave ovens interfering with their service. These guys are able to transmit 30 miles, and their installation is up and running in two locations right now.
Someone Mod this parent up!
Someone is finally talking with some sense, instead of waving their arms and shouting without reading any of the facts. Again, mod the parent up!
Actually, Shawn Fanning could still get rich. He just needs to write a book about the rise and fall of Napster. Give it a catchy title and make sure it doesn't sound like 3 years olds ramblings that should have been scrawled out in crayon, and he'd probably sell a few hundred thousand copies.
You know, I could care less if there are 5 or 5000 Linux distributions out there. But I'm really getting tired of the lack of binary compatability between distributions. And when I say that, I mean lack of binary compatability all the way from libc up to the desktop environment. I can compile simple command line apps and have it run on most distributions, but the second I start using extra libraries (like GTK+) I start running into compatability problems between distros.
/usr/lib and you'll be okay" either!
Distro A has the library, but it's a different filename since it's a newer version than the one in Distro B. Bah! The best tech that MS stole was COM objects. Just cram all the necessary versions into a single file, and let the runtime linker figure it out on the fly.
Well, I'm not trying to say that we need that sort of extra functionality/overhead, but I do want to say that Linux will take off like a shot at soon as developers have a steady target to aim for. The sooner all the major distros decide on a list of libraries that make up a standard linux distribution, the sooner I'll be able to start telling my friends and family that they should switch.
RPM, apt, deb, and even slack's TGZ all have the same problem. The application/library is compiled and packaged for a single version of a single distribution. Sometimes you can take them to another version or distro and it will work, but most often not. With a little fussing, you can usually put together some symlinks on a few libs that will at least get the app to run, but certain features won't work correctly, or the app will crash because a certain interface isn't exposed by this version of a lib. Even if it did run 100% correctly after you made the necessary symlinks, that still isn't good enough, since you had to manually manipulate the system in order to get the app to run. I don't tell my family to run regedit when they can't get an item out of the "Uninstall Application" menu (I fix it for them next time I'm over there), so I'm not going to tell them to "Just make a few symlinks in
Man this continual problem pisses me off...
It's so basic that I was sure that it would have been worked out by now. I've looked and looked and found nothing. The Linux Standard Base doesn't even come close to defining everything that is necessary for binary compatability between distros, and google hasn't given me any other good leads.
If I'm missing the big red neon sign that points to the solution, then please do share it with me. But if I simply haven't found it because it doesn't exist, then we should defenitely evaluate the value that this would add to Linux, and seriously consider its immediate implementation.
You must not be very familiar with Solaris at all. Solaris is anything but "fast and stable". XSun is horribly lathargic, and Solaris is known to have core libraries that leak memory (which is why Apache allows you to set the maximum requests serviced per forked child).
As for Sun making great hardware, that is more bunk. The SPARC architecture is an open standard. Anyone who actually uses these things knows that there are several different manufacturers that you can go to for processors and equipment.
What Sun does well is selling their name, and R&D. Sun has been the first to come out with exciting new technologies on several occasions. They aren't always implemented in the best way, and sometimes they aren't even realistically useful tech, but they do put the man hours into it, which is quite commendable (especially when everyone is still whining about the economy).
I'll agree with you about CDE though, it vigorously sucks donkey balls through a garden hose like a french whore on speed.
I have to whole heartedly agree with you on this. The US government is, and never was, charged with the responsibility to ensure that a business model that made money in the past is able to make money in the future.
If they were, we'd still see horse drawn buggies, since they auto would have been banned. It cuts into buggy sales, and we can't have that.
Or, if you want to allow products to be replaced (ie tapes were replaced by CDs, so buggies can be replaced by cars) but not allow business models that feed off of others, then I have another argument. How do you explain taxi services and forms of public transportation? You can't tell me that these don't cut into auto sales. Why have a car when you live and work in downtown Chicago? Or even take a bike.
The government endorses public transportation, but it shuns public music distribution channels? What the fuck is up with that?
All I can say, is I'm getting sick of these government officials being on the side of large businesses simply because they are large campaign contributers. I have a nice new law for you. If you accept money from a corporation or individual, you may not vote on any issues directly relating to that corporation or individual's well being. In other words, if the RIAA 'donates' $100k toward your campaign, and you accept it, you aren't allowed to vote on any bill, or push any legislation, that has to do with digital rights management, music copyright, or anything else the RIAA gets their fingers into. I guess you better stick to water purification and eco-system issues.
Damn polititians....
Excuse me, but last time I checked, my rights were inalienable and included everything that I didn't willingly give up for the good of society. It has nothing to do with what lawyers have deemed acceptable for me to have. If your business sense is as acute as your legal sense, it's no wonder your portal is now "defunct".
I'm sick of seeing companies changing the price model for bandwidth. Once you have an OC-192, what the hell does it matter if you fill it, or not. You're already paying for the whole damn thing, whether it is full or not. Some people will use the network like mad, and some won't. That's how it works. Not to mention, that's why we pay for your fucking service.
I may download 18 full 650MB isos one month, and the next month I spend all of my time writing code and checking my email. That's the way it is supposed to work. What one guy doesn't use, the other will.
Besides, if you're tired of your users filling up your OC-192 24 hours a day with peer to peer filesharing apps, why don't you try doing something truly innovative. Start your own server to act as a proxy, and firewall the users from actually passing through your router. Now you've just removed all of the pointless "I'm still here" packets, and only left the data transfer packets. What's better, your network users can share all they want over your internal network, and it won't cost you a dime in additional internet bandwidth. What a fucking idea!
Sorry for being such a prick about this, but I've had my fill of clueless network admins who insist on fighting what their users really want.