Re:Cool project resulting from a big problem?
on
RPM Dependency Graph
·
· Score: 1
And then what happens when there is a new version of one "option" in your "old" package that needs one new lib from the "base" package? Your idea doesn't scale AT ALL, nor does it make any sense.
You're right. I totally forgot to explain how this type of package management paradigm would deal with legacy application support, and considering that I'm posting on slashdot completeness is really important for costructive dialog to be possible. I admit it -- I goofed.
For the sake of clarity, let's call these "bigger packages" packages and what we consider to be a package now a "micropackage". Inside this system, a "package" called "legacy application support" would be installed upon the user's request (probably by default. It would be made up of options, each one a library that has been removed from "base" (or whatever package it is native to) to make room for a newer, more stable, more functional version. When updating software that requires a new library from "base", the old library option would be moved from "base" to "legacy". Of course, this would only be inside the package managment database -- the files would still be there on disk for applications to use -- and the responsibility for keeping track of that package would be moved from "base" to "legacy". All programs installed that depended on the old version of the library would still function as a result of the excelent version number naming policy discussed in the "Management vs. Policy" post above.
No, it sounds like you have no idea what you are talking about and you've also never used debian which accomplishes this in a sane way via pseudo-packages and tasks.
This one actually stings. I have used debian, although I was only recently enlightened with respect to "tasks", and I would like to think I know something about package management systems. On the other hand, this kind of criticism may be exactly the impetus I need to start a proof of concept project. Time will tell.
However, tasks are not quite what I had in mind. The analogous idea would be to make it impossible to have packages outside of tasks. At first this seems like a huge limitation. However, with the ability to move packages between tasks and rename them as needed, it opens up a whole new world of usability and managability. People like you and me can use modern package management systems like rpm and deb and keep all the important stuff in mind at the same time, but it can be a big chore to dig through when there's a problem. For new users or those that aren't technologically inclined, package management can be an insurmountable obstacle.
I completely agree with you - windows installers can (and often do) spray files all over the place. Sure, windows has an add/remove control panel, but installers aren't required to place an entry there or on the start menu to make uninstallation easy. An installer could drop files all over the place and offer no way to clean them up. However, the windows model has two big advantages over linux in this respect:
1. There is a standard, accepted way to install and uninstall programs. Installer wizards for installation, the add/remove control panel to remove them. Installers can choose not to do this, but programs that don't make it easy to uninstall themselves don't endear themselves to the user, and offering an uninstall option is really easy to do.
2. When installing DirectX, you run one program and it installs everything. It doesn't offer an uninstall feature and new versions are often bug-ridden, a terrible combination, but you don't have to go out and install the pieces one-by-one yourself, nor do you have to worry about backwards compatibility.
(btw, yes I'm aware that you can download dx uninstall utilities off the net, but they don't come bundled. I'm also aware of how much code bloat its backwards compatibility creates.)
On the other hand, there are some big disadvantages that come with the windows model:
1. You must execute freshly downloaded code to install an app, except possibly in the case of an MSI. This isn't increasing the security risk, as you have to execute freshly downloaded code every time you run a freshly downloaded program anyway, but it does increase the chance that a bug in the latest version of the installer would prevent you from installing or would cause problems with the system.
2. Programs aren't required to register for uninstallation. One very good example is software that installs spyware, but conveniently forgets to uninstall it when you remove the program. I know we should all run ad-aware regularly anyway, but it's still not a good idea to leave the responsibility of uninstalling a program with the program itself.
What I'd like to see is a combination of the techniques commonly used on windows with the package management systems used on linux to create a better solution. The idea would be to have a system:
-That has a standard way of installing and uninstalling programs. -Whose packages are made up of large groups of files providing a specific capability (functional applications) rather than a set of a few shared libraries or an executable. -With a single package management application that is in total control of the install process, rather than leaving this important task to the individual applications. -That makes it easy and convenient to uninstall _any_ installed application.
That sounds really cool -- I'll have to check it out the next time I try a deb-based disto. However, it still doesn't solve the problem of overcomplicated webs of dependencies and the lack of a single standard package system.
Cool project resulting from a big problem?
on
RPM Dependency Graph
·
· Score: 3, Interesting
This is a really neat project. I'm definitely going to download the code and generate that map, just to see how massively hairy it is. However, the fact that a project like this is newsworthy (i.e. produces such interest-generating and complicated output) seems to suggest that perhaps package management on linux (rpm, deb, whatever...) has just served to cover up a much larger problem.
Package management makes it possible and (depending on your point of view) easy to update an entire system using apt-get or up2date (or whatever). It also allows users to install and uninstall additional programs with a minimum of fuss. I think it's safe to say that without package management, system administration would be much harder. However, what's been created to support this system is a visually attractive, yet tangled web of dependencies and interrelations between software packages that make maintaining multiple versions of shared libraries for legacy as well as bleeding edge applications, creating backwards and forwards compatilbe software packages, and installing software that isn't aware of the package system in use on the machine a real pain and sometimes (for non-ultragurus) impossible.
In my opinion, what we really need is a single, standard package system for all linux-based distros. Chuck rpm, chuck deb, chuck them both and create a new one incorporating the best features of both, I don't care, but I think it really needs to be done. Also, I think a change in what we think of as a 'package' is in order, a minimum functionality so to speak. If a user cannot make the statement: "If I install (package X) then I can do (process Y)," then package X does is not significant enough by itself and should be incorporated into another package that requires/uses it. Examples:
If I install the "linux base" package, I can boot an absolutely bare-bones system.
If I install the "textual system" package, I will have access to a complete textual system, including a text-mode console login, text-mode editing tools (vi for example), a textual system configuration manager, etc...
If I install the "graphical system" package, I can boot into a system that is completely graphical all the way, including a graphical login, desktop environment, a graphical system configuration tool, a web browser, etc...
If I install the "office suite" package, I will have access to a word processing program, a spreadsheet editing program, and a presentation creation program.
Individual options (e.g. vi or emacs) within each package should be just that - options, not separate packages. Sure, a user may install more than he or she needs if packages are this "collective", but in my opinion, users would be much happier having an office suite installed when they only really need document editing capabilities than with a default OS install that takes up more than 1GB because it comes with everything preinstalled so regular users won't have to puzzle out the overcomplicated package managment system in order to install something else.
Don't try to buy off a congressional representative. The MPAA and RIAA have more money than you and everyone else could ever hope to donate to an EFF fund, and since the bills go to the highest bidder you're out of luck. On the other hand, tv time comes at a fixed cost/minute. Instead of buying a senator/house rep directly, make an example out of one of them. Run ads. Get them thrown out of office. It costs much less than bidding against the [MP,RI]AA and more senators will take note.
...their existance points at a deeper problem. The linux security model is based off of the unix security model which basically expected users to do two things: 1. Log in through a text mode terminal. and 2. Run programs (i.e. use cpu time and memory).
Since the demands of computer users began to expand beyond those original expectations (graphical interface, selective access to administrative abilities, etc...) the solution has always been to write a suid program that simply snags root priveleges and tries not to let the user do anything bad while it's running. Sure, it works, and linux-based systems have come a long long way, but the fundamental problem remains: to the OS, a user is a user is a user (except root). The linux security model hasn't expanded to meet new challenges, it's been circumvented by suid programs and as a result instead of a single point of possible penetration (a problem with the kernel) there are hundreds of possible ways to take over the system and hundreds of programs that must be maintained in order to keep the system secure.
Yes, chroot is an absolutely beautiful solution in many cases. No, I'm not saying linux is terribly insecure. What I am saying is that a new philosophy needs to be employed in designing security models: if a program has to become root (or the equivalent) to perform its function, something is wrong with the security model. It seems to me that this kind of thinking, combined with an elegant system to keep track of who is allowed to do what, would do wonders for the maintainability and usability of linux based OSs.
I've been poking my newbie nose around in scheduling for a little while, and while I still know very little I've found the field very interesting. It's always neat to see new features and techniques being tried, but there's a feature that exists in the windows nt scheduler that (as far as I can tell) is absent in *nix operating systems. Winnt maintains (I think) four process queues (realtime, high, normal, and idle) into which all processes fall. Every time the scheduler is run, it checks to see if any "realtime" processes can be run, then "high", then "normal", and finally "idle". Processes in "less important" queues are only run if all processes in "more important" queues cannot be run (i.e. they're blocking on input or whatever), or those queues are empty. I find this very useful because I can set a long-running cpu dependent process to "idle" priority and it will be run at nearly 100% cpu usage when the machine is idle, but will instantly get out of the way and not be run at all if I choose to run something else (e.g. a game), no matter how high it's "goodness" value gets from not using any cpu time.
Is there any reason why something like this isn't implemented in Linux or FreeBSD? Low on the developers' feature priority list (har har)? Too difficult? Unnecessary?
Thanks. I'd appreciate any feedback.
Not all web proxys are p2p software, but...
on
Triangle Boy Lives
·
· Score: 3, Informative
...this one is. It just bounces requests off of other triangle boy users, as opposed to a server you've set up at home.
One solution might be to perform the randomization on the client side and display the result. That way the user can see that the answers have been munged before they are sent.
<sarcasm> That would certainly be pyschologically assuring. It would show users that the data they entered could not be used to target them specifically but could still provide useful group demographics to the company. As a web retailer, I can't wait for this to become widespread. I'll put up a registration form on my web site with a "randomize" button next to the submit button. When a user clicks on the randomize button, the javascript on the page will back up the real information that the customer entered into another set of variables, then randomize what the display boxes show to make it look like the data has been randomized. When that user then clicks the submit button, which belongs to the form containing all the backed up true values in "hidden" type inputs, the customer's data will be sent through a POST so the user can't see that his or her data has not been protected.
It's brilliant. It gets me the data I want without regard for the user's privacy and it solves the problem of the user not trusting my web-based business.
<sarcasm> <!-- does sarcasm stack? --> But what if some random user clicks "view source" and finds out what I'm doing? Well, of course they'll report it to the eff which will muster it's army of thousands of high paid lawyers, public relations masters, and black belt ninjas to sue me out of business, run television ad campaigns to keep the public informed, and quickly and (get this) anonymously take out all my top execs, just like they've always done when combatting such problems as Passport(R)'s invasions of privacy and the DMCA. </sarcasm> </sarcasm>
The GIF file format is not patented. However, the compression scheme that makes it smaller than an uncompressed bmp file (i.e. usable), LZW, is patented. You can make all the gifs you want and write software that makes gifs without paying a cent. If you want to have a 640x480 image come out of your program smaller than 307KB, then you have to pay.
I disagree. The GPL says that if you take GPL'd source code, modify it, and then distribute binaries compiled from that modified source, then you have to release that source back to the community. This means that if a piece of software is GPL'd or a piece of software uses GPL'd code, then you can always get that source code. If you can get the source code, you can compile the binaries. If you can compile the binaries, you can use the software for free. Of course, you may not be able to obtain all of the resources that program needs if they were proprietary (e.g. movies, maps, databases) so you may not be able to _use_ it as you would the proprietary distribution that includes that software, but the software _itself_ would still be free. Quake and Quake II are good examples of this. The source is free, the data files are copyrighted.
Also, the GPL does allow you to _use_ the software for free. The "community service" part comes in as a stabilizer in the case that you want to use the code. It ensures that if you take from the community (using their coding time to your advantage) you have to give back to the community (allowing them to use your coding time to their advantage).
From their win2k/linux comparison page: Better business alignment with straightforward licensing and clarity of intellectual property ownership [win2k] The Microsoft licensing model does not contain licensing provisions that require an OEM, and potentially its licensees, to disclose the source code for its intellectual property in a widespread fashion to open source participants. An OEM building a server appliance with Windows 2000 Server operating systems and the SAK has the assurance the software code and added value it develops remain the OEM's intellectual property. [linux] To ensure proper management of its intellectual property rights, an OEM must carefully examine an array of licensing complexities around the General Public License (GPL) that govern Linux. These complexities have resulted in embedded and dedicated operating system companies such as Wind River saying that they are seeing "a growing problem due to the growing uncertainty of using GPL-based code in embedded devices". An example of this risk can be taken from NVIDIA. An NVIDIA programmer, in the course of developing a driver for one of its products, used a portion of code from a freely available video driver. The developer failed to realize the code was licensed under the GPL and would therefore require NVIDIA to release the source code for its entire driver. Because NVIDIA did not want to release the source code to its commercial software, the company incurred substantial cost to develop a new driver that did not contain the GPL code.
Companies need to recognize that in embedded and dedicated devices, such as server appliances, significant gray areas exist in the implications of the GPL's terms. Some forms of code linking and commingling may or may not trigger legal obligations under the GPL. As Michael Scott and Michael Krieger, a lawyer and computer science professor respectively, recently wrote, "Rare is the month when a lawyer who specializes in technology does not have a new client asking for help in untangling an open source code problem".
Yeah, last time I checked if you use parts of or modify the GPL'd source code that comes with a linux distribution you have to give your product back to the community. When you use parts of or modify the source code that comes with windows, you....ummm.....
No joke. It's an old (but very functional) tv so I'm not too worried about hurting its cosmetic appearance, and there really isn't that much information on the lower 9th of the screen anyway. Programs with scrolling headlines/stock tickers (i.e. news) are a _lot_ more watchable when my eyes aren't constantly being sucked to the bottom the screen. Same thing for shows with network promos, like star trek on TNN. They vertically squish the picture instead of replacing part of it so there's literally nothing missing. I had no idea how much those distractions were interfering with my viewing until I got rid of them.
Personally, I'm very pleased with the results. Of course, I don't watch a great deal of TV and I never use it with tv-out on my computer so this kind of thing may not be right for everyone.
have a standard installer? There's rpm, there's deb, there's pkg (or whatever slack uses), there's the ports system, and there are probably more. I agree that the community could benefit greatly from more standardization. I just don't think we have it yet.
This kind of technology has already been implemented in many gnutella clients. Gnucleus (my favorite one) can be configured to use random ports.
I was was working on a custom tailored compression algorithm for gnutella search traffic that would reduce search network traffic bandwidth usage to (a rough guess) 20% of what it is now, but that got shelved for a while when real life (tm) suddenly became a priority. I will undoubtedly resume work on it soon, but while I was toying with a few different ideas regarding the gnutella protocol I came up with an idea for a completely unrecognisable (from the ISP's point of view) communication system for p2p. Briefly:
Step 1: Use the current system of random port assignments using gping/gpong/GWebCache to spread node data. Step 2: Upon connecting to another node, before any handshaking of any kind is done, exchange public keys (generated by each instance of the node software upon install) and use them to set up an OpenPGP compliant encrypted tunnel. Step 3: Use the standard gnutella three way handshake to exchange node data and negotiate options (e.g. QRP support, compression, etc...) Step 4: Begin normal network operations.
It's undetectable because there is no distinguishable pattern even if the ISP decides to sniff packets. -The ports and IP addresses are random. -The first 2 kbits (or whatever length) of the connection are random (public keys would be generated randomly by the node software on install). Especially paranoid nodes could generate a new key pair for each connection. -All the data following that would be encrypted (random).
Since everything (IPs, ports, data) would be random (not to mention protected from snoops!) ISPs would have no way of blocking it. Their only option would be to execute a man in the middle attack, but that would require modifying the data stream which, while undetectable & successful in the event that the connection in question is in fact a gnutella connection, would really confuse anything else.
In short, an ISP would not be able to check a connection without destroying it in the case that it's not p2p.
I don't think their actions have anything to do with copyright or piracy. Think about it: if a cable company has a node serving a neighborhood through a single coax loop providing 30Mbit of shared bandwidth with each user being able to snag up to 3Mbit downstream (the situation where I live), and there are just three people on the loop who are downloading 24/7 using some fastrack servent, then nearly a third of their bandwidth capacity is being used by three people.
They're not blocking fastrack for copyright/piracy reasons. They're doing it because fastrack users consume a _lot_ of bandwidth and internet service provider business models are completely and utterly dependent on customers that don't fully use what they pay for. In the same way that modem ISPs never have enough modems for every customer to dial in at once, cable ISPs never have enough bandwidth for every customer to download (at full speed) at once. They blocked fastrack because:
-Blocking it frees up a _whole lot_ of bandwidth. That bandwidth can then be oversold to many more customers, increasing revenue without having to increase network capacity. -99.99999999999999999999999999999999999 9999999% of all activity on the fastrack network violates copyright. Users have no means of legal retaliation. -It's used by relatively few people. Blocking port 21 (ftp) would cause an uproar. Blocking port 1214 (fastrack network search traffic) caused only the tiniest of squeaks.
I'd say there's a difference there. People want good web browsers, people want good office suites, people want journaling file systems. Sure, the average user may not know what a journaling file system is, but he sure doesn't want to have to deal with fixing the file system after a crash or power outage, which is basically the same thing.
"People" don't want DRM.
Average users don't want it because it restricts their abitily to use information tools and toys like computers and portable music players. Deveopers don't want it because "perfect" DRM is just plain impossible to code. Information philosophers don't want it because they understand that the core ideas behind DRM (the "renting", "expiring", and "control" of information in the posession of untrusted parties) go against the fundamental laws of the "physics of information". Economists who understand what's going on don't want it because they don't want to see huge pieces of the economy resting upon a cracked (har har) foundation.
Large media-based corporations want it because they can use it to fatten their wallets and they can get away with it because joe average doesn't know enough to be able (or willing) to put up a fight.
A large media-based corporation controls windows and is influenced by other large media-based corporations. Developers control linux, and are influenced by insightful information philosophers and technologically astute economists, none of whom are saying "Linux has no good Digital Rights Management!"
Actually, I think there's another important issue here. If the MPAA sends out a search packet containing "star wars episode II" and your computer responded with a search hit packet saying "I have that! Here's a list of hits to your search that I have on my computer." then did they really enter your computer without your permission? Setting aside the debate as to whether it's "right" for the MPAA to do this or even operate their business under current copyright law, this brings up an interesting question.
Isn't that the digital analogue (har har) of the MPAA calling you up on the phone and asking "Do you have a pirated copy of Star Wars Episode II: Attack of The Clones?" and you replying "Sure do! If you want a copy, send me a self addressed stamped envelope big enough for two cds."? I certainly wouldn't consider _that_ situation an invasion of privacy.
Of course, law, information, and copyright operate differently in the realm of computers and the internet. You can even sign a binding contract that holds up in court simply by hitting the tab key a few times on your computer and then pressing the enter key (choosing "I Agree" after a EULA).
In my IRC days a lot of people would operate file servers, but upon connecting they would display a message to the effect of:
You may not download any file from this server or obtain any file listings. You must disconnect immediately! If you stay connected or interact with this server in any way other than disconnecting, you are violating the terms of the Internet Privacy Act signed into law by Bill Clinton in 1995 and will be guilty of a federal crime.
IANAL. I don't remember the text exactly. However, would something like this still work if the user's computer hit "I Agree" automatically or blocked the warning text from being displayed?
If so, then couldn't all p2p packets carry a disclaimer such as this one to prevent "unauthorized" usage by the *AA? If not, then where do you draw the line between a user's action and a computer's action? After all, when you click I agree, isn't it _Windows_ that sent the WM_LEFTCLICK (or whatever) message to the window causing the software to install?
A few years back the search engine metacrawer ("Search the search engines!") set up a service called "metaspy" that showed search queries which were being processed. Aparently they didn't want to get into any trouble by exposing kids to uncensored searches, so they set up two viewing modes, each with an icon. The "clean" version's icon is a typical sleuth character in green holding a magnifying glass and a pipe; this was the old metaspy icon. The new "metaspy exposed" icon for unfiltered search viewing also features a typical sleuth character, but one whose trenchcoat is open and is clearly not wearing and pants.
I'm not sure how ati's maxx technology was supposed to work, but having spent a lot of time drooling over 3dfx cards in my gaming days I think I can shed some light on the subject.
The voodoo 2s (like the original voodoo graphics) used a pass-though cable to add 3d support to an existing machine. A cable would come out of the 2d card and go directly into the voodoo 2. A cable would then connect the voodoo 2 to the display device. The voodoo 2 was the first 3dfx card to support SLI, scan line interleave, where one card would render the even scan lines and the other would render the odd ones. The speed was about equal to a voodoo 3 2000, and resolution was limited to a max of 1024x768. This configuration was only obtainable by adding another voodoo 2 pci card of the same brand and memory configuration and connecting them with a special cable.
The voodoo 3 was not capable of doing SLI. Although SLI was a very popular option with gamers, the voodoo 3 did not have support for it, largely because it was more of an improved banshee (technology-wise) than a voodoo 2. 3dfx chose to use the 'voodoo' name in order to associate it with the successful voodoo line rather than the banshee card which was, for lack of a better word, an utter failure.
The voodoo 4 could not do SLI either. While it used 3dfx's VSA 100 chip which was capable of doing SLI, the defining characteristic of the voodoo 4 card was that it had only one gpu.
SLI was brought back with the voodoo 5. Instead of returning to the multiple-card-voodoo-2 method of doing SLI, 3dfx chose to put all of the chips on the same board. The voodoo 5 5500 had two VSA 100s, whereas the voodoo 5 6000 had four.
That's the deal with 3dfx.
Regarding MAXX technology conflicting with NT kernel based OSs, I don't think it would just becase it supported SLI. One of my friends is using a voodoo 5 5500 card with windows 2000 right now, and he hasn't had any problems. However, that doesn't rule out problems with other parts of the MAXX architecture.
you can put that memory bandwidth to good use. Normally, the asus board , using the via kt333 chipset, runs the fsb at 133MHz DDR and the memory bus at 166MHz DDR (if you have PC2700 memory). In order to get that extra memory bandwidth to the cpu, you have to increase the fsb clock to 166MHz DDR. If you're not into overclocking you cpu 25%, then you have to lower the clock mulitplier to compensate. The asus board offers a 1/5 clock divider for your pci bus so all your other devices can run in spec. Have fun:).
P.S. The MHz stuff. MHz only means millions of cycles per second. Exactly what that means depends on how you define "cycle". If you're using the accepted definition of a cycle, in terms of memory, then you're talking about a cycle bounded by the event which occurs every time your bus does this:
_ / \_/
(I'm not the best ascii artist but you get the idea) and the memory bus operates at 166MHz. However, if you're calling a cycle the event that occurs every time the bus can put a bit on a data line, then the memory bus operates at 333MHz. Either way, you're still going to get a maximum throughput of 2.7GB/s.
P.P.S. If you want to change your fsb from 133MHz to 166MHz then you have to get a cpu with a rated frequency into which 166 will divide nicely. That means the XP 2000+ (1666MHz) or the XP 1500+ (1333MHz). If you get any other processor, you'll have to overclock or underclock a little since the cpu multiplier can only be set to multiples of 1/2.
Thought provoking idea. How about a system where a value of X dollars is declared for a certain piece of "intellectual property" when it is copyrighted/patented. %1 of X per year is paid in taxes. After the owner of that piece intellectual propery gains X dollars in income from its licensing, the work becomes public domain. X could be adjusted at any time to allow the copyright holder to retain ownership of the work, but that entity would have to pay "back taxes."
It works because: -Entities are encouraged to produce works that are of high value to the public. -Writers of free software (beer or speech) can retain their rights indefinitely as long as they don't charge for it, but can still accept donations. -Passing the 1% tax on to consumers would just cause the work to pass into public domain faster.
Slashdot Mirror
And then what happens when there is a new version of one "option" in your "old" package that needs one new lib from the "base" package?
Your idea doesn't scale AT ALL, nor does it make any sense.
You're right. I totally forgot to explain how this type of package management paradigm would deal with legacy application support, and considering that I'm posting on slashdot completeness is really important for costructive dialog to be possible. I admit it -- I goofed.
For the sake of clarity, let's call these "bigger packages" packages and what we consider to be a package now a "micropackage". Inside this system, a "package" called "legacy application support" would be installed upon the user's request (probably by default. It would be made up of options, each one a library that has been removed from "base" (or whatever package it is native to) to make room for a newer, more stable, more functional version. When updating software that requires a new library from "base", the old library option would be moved from "base" to "legacy". Of course, this would only be inside the package managment database -- the files would still be there on disk for applications to use -- and the responsibility for keeping track of that package would be moved from "base" to "legacy". All programs installed that depended on the old version of the library would still function as a result of the excelent version number naming policy discussed in the "Management vs. Policy" post above.
No, it sounds like you have no idea what you are talking about and you've also never used debian which accomplishes this in a sane way via pseudo-packages and tasks.
This one actually stings. I have used debian, although I was only recently enlightened with respect to "tasks", and I would like to think I know something about package management systems. On the other hand, this kind of criticism may be exactly the impetus I need to start a proof of concept project. Time will tell.
However, tasks are not quite what I had in mind. The analogous idea would be to make it impossible to have packages outside of tasks. At first this seems like a huge limitation. However, with the ability to move packages between tasks and rename them as needed, it opens up a whole new world of usability and managability. People like you and me can use modern package management systems like rpm and deb and keep all the important stuff in mind at the same time, but it can be a big chore to dig through when there's a problem. For new users or those that aren't technologically inclined, package management can be an insurmountable obstacle.
I completely agree with you - windows installers can (and often do) spray files all over the place. Sure, windows has an add/remove control panel, but installers aren't required to place an entry there or on the start menu to make uninstallation easy. An installer could drop files all over the place and offer no way to clean them up. However, the windows model has two big advantages over linux in this respect:
1. There is a standard, accepted way to install and uninstall programs. Installer wizards for installation, the add/remove control panel to remove them. Installers can choose not to do this, but programs that don't make it easy to uninstall themselves don't endear themselves to the user, and offering an uninstall option is really easy to do.
2. When installing DirectX, you run one program and it installs everything. It doesn't offer an uninstall feature and new versions are often bug-ridden, a terrible combination, but you don't have to go out and install the pieces one-by-one yourself, nor do you have to worry about backwards compatibility.
(btw, yes I'm aware that you can download dx uninstall utilities off the net, but they don't come bundled. I'm also aware of how much code bloat its backwards compatibility creates.)
On the other hand, there are some big disadvantages that come with the windows model:
1. You must execute freshly downloaded code to install an app, except possibly in the case of an MSI. This isn't increasing the security risk, as you have to execute freshly downloaded code every time you run a freshly downloaded program anyway, but it does increase the chance that a bug in the latest version of the installer would prevent you from installing or would cause problems with the system.
2. Programs aren't required to register for uninstallation. One very good example is software that installs spyware, but conveniently forgets to uninstall it when you remove the program. I know we should all run ad-aware regularly anyway, but it's still not a good idea to leave the responsibility of uninstalling a program with the program itself.
What I'd like to see is a combination of the techniques commonly used on windows with the package management systems used on linux to create a better solution. The idea would be to have a system:
-That has a standard way of installing and uninstalling programs.
-Whose packages are made up of large groups of files providing a specific capability (functional applications) rather than a set of a few shared libraries or an executable.
-With a single package management application that is in total control of the install process, rather than leaving this important task to the individual applications.
-That makes it easy and convenient to uninstall _any_ installed application.
That sounds really cool -- I'll have to check it out the next time I try a deb-based disto. However, it still doesn't solve the problem of overcomplicated webs of dependencies and the lack of a single standard package system.
This is a really neat project. I'm definitely going to download the code and generate that map, just to see how massively hairy it is. However, the fact that a project like this is newsworthy (i.e. produces such interest-generating and complicated output) seems to suggest that perhaps package management on linux (rpm, deb, whatever...) has just served to cover up a much larger problem.
Package management makes it possible and (depending on your point of view) easy to update an entire system using apt-get or up2date (or whatever). It also allows users to install and uninstall additional programs with a minimum of fuss. I think it's safe to say that without package management, system administration would be much harder. However, what's been created to support this system is a visually attractive, yet tangled web of dependencies and interrelations between software packages that make maintaining multiple versions of shared libraries for legacy as well as bleeding edge applications, creating backwards and forwards compatilbe software packages, and installing software that isn't aware of the package system in use on the machine a real pain and sometimes (for non-ultragurus) impossible.
In my opinion, what we really need is a single, standard package system for all linux-based distros. Chuck rpm, chuck deb, chuck them both and create a new one incorporating the best features of both, I don't care, but I think it really needs to be done. Also, I think a change in what we think of as a 'package' is in order, a minimum functionality so to speak. If a user cannot make the statement: "If I install (package X) then I can do (process Y)," then package X does is not significant enough by itself and should be incorporated into another package that requires/uses it. Examples:
If I install the "linux base" package, I can boot an absolutely bare-bones system.
If I install the "textual system" package, I will have access to a complete textual system, including a text-mode console login, text-mode editing tools (vi for example), a textual system configuration manager, etc...
If I install the "graphical system" package, I can boot into a system that is completely graphical all the way, including a graphical login, desktop environment, a graphical system configuration tool, a web browser, etc...
If I install the "office suite" package, I will have access to a word processing program, a spreadsheet editing program, and a presentation creation program.
Individual options (e.g. vi or emacs) within each package should be just that - options, not separate packages. Sure, a user may install more than he or she needs if packages are this "collective", but in my opinion, users would be much happier having an office suite installed when they only really need document editing capabilities than with a default OS install that takes up more than 1GB because it comes with everything preinstalled so regular users won't have to puzzle out the overcomplicated package managment system in order to install something else.
</rant>
Sound good?
Don't try to buy off a congressional representative. The MPAA and RIAA have more money than you and everyone else could ever hope to donate to an EFF fund, and since the bills go to the highest bidder you're out of luck. On the other hand, tv time comes at a fixed cost/minute. Instead of buying a senator/house rep directly, make an example out of one of them. Run ads. Get them thrown out of office. It costs much less than bidding against the [MP,RI]AA and more senators will take note.
I'm emailing the EFF right now to suggest this.
...their existance points at a deeper problem. The linux security model is based off of the unix security model which basically expected users to do two things:
1. Log in through a text mode terminal.
and
2. Run programs (i.e. use cpu time and memory).
Since the demands of computer users began to expand beyond those original expectations (graphical interface, selective access to administrative abilities, etc...) the solution has always been to write a suid program that simply snags root priveleges and tries not to let the user do anything bad while it's running. Sure, it works, and linux-based systems have come a long long way, but the fundamental problem remains: to the OS, a user is a user is a user (except root). The linux security model hasn't expanded to meet new challenges, it's been circumvented by suid programs and as a result instead of a single point of possible penetration (a problem with the kernel) there are hundreds of possible ways to take over the system and hundreds of programs that must be maintained in order to keep the system secure.
Yes, chroot is an absolutely beautiful solution in many cases. No, I'm not saying linux is terribly insecure. What I am saying is that a new philosophy needs to be employed in designing security models: if a program has to become root (or the equivalent) to perform its function, something is wrong with the security model. It seems to me that this kind of thinking, combined with an elegant system to keep track of who is allowed to do what, would do wonders for the maintainability and usability of linux based OSs.
ATDT18004693288
I've been poking my newbie nose around in scheduling for a little while, and while I still know very little I've found the field very interesting. It's always neat to see new features and techniques being tried, but there's a feature that exists in the windows nt scheduler that (as far as I can tell) is absent in *nix operating systems. Winnt maintains (I think) four process queues (realtime, high, normal, and idle) into which all processes fall. Every time the scheduler is run, it checks to see if any "realtime" processes can be run, then "high", then "normal", and finally "idle". Processes in "less important" queues are only run if all processes in "more important" queues cannot be run (i.e. they're blocking on input or whatever), or those queues are empty. I find this very useful because I can set a long-running cpu dependent process to "idle" priority and it will be run at nearly 100% cpu usage when the machine is idle, but will instantly get out of the way and not be run at all if I choose to run something else (e.g. a game), no matter how high it's "goodness" value gets from not using any cpu time.
Is there any reason why something like this isn't implemented in Linux or FreeBSD? Low on the developers' feature priority list (har har)? Too difficult? Unnecessary?
Thanks. I'd appreciate any feedback.
...this one is. It just bounces requests off of other triangle boy users, as opposed to a server you've set up at home.
One solution might be to perform the randomization on the client side and display the result. That way the user can see that the answers have been munged before they are sent.
<sarcasm>
That would certainly be pyschologically assuring. It would show users that the data they entered could not be used to target them specifically but could still provide useful group demographics to the company. As a web retailer, I can't wait for this to become widespread. I'll put up a registration form on my web site with a "randomize" button next to the submit button. When a user clicks on the randomize button, the javascript on the page will back up the real information that the customer entered into another set of variables, then randomize what the display boxes show to make it look like the data has been randomized. When that user then clicks the submit button, which belongs to the form containing all the backed up true values in "hidden" type inputs, the customer's data will be sent through a POST so the user can't see that his or her data has not been protected.
It's brilliant. It gets me the data I want without regard for the user's privacy and it solves the problem of the user not trusting my web-based business.
<sarcasm> <!-- does sarcasm stack? -->
But what if some random user clicks "view source" and finds out what I'm doing? Well, of course they'll report it to the eff which will muster it's army of thousands of high paid lawyers, public relations masters, and black belt ninjas to sue me out of business, run television ad campaigns to keep the public informed, and quickly and (get this) anonymously take out all my top execs, just like they've always done when combatting such problems as Passport(R)'s invasions of privacy and the DMCA.
</sarcasm>
</sarcasm>
The GIF file format is not patented. However, the compression scheme that makes it smaller than an uncompressed bmp file (i.e. usable), LZW, is patented. You can make all the gifs you want and write software that makes gifs without paying a cent. If you want to have a 640x480 image come out of your program smaller than 307KB, then you have to pay.
I disagree. The GPL says that if you take GPL'd source code, modify it, and then distribute binaries compiled from that modified source, then you have to release that source back to the community. This means that if a piece of software is GPL'd or a piece of software uses GPL'd code, then you can always get that source code. If you can get the source code, you can compile the binaries. If you can compile the binaries, you can use the software for free. Of course, you may not be able to obtain all of the resources that program needs if they were proprietary (e.g. movies, maps, databases) so you may not be able to _use_ it as you would the proprietary distribution that includes that software, but the software _itself_ would still be free. Quake and Quake II are good examples of this. The source is free, the data files are copyrighted.
Also, the GPL does allow you to _use_ the software for free. The "community service" part comes in as a stabilizer in the case that you want to use the code. It ensures that if you take from the community (using their coding time to your advantage) you have to give back to the community (allowing them to use your coding time to their advantage).
From their win2k/linux comparison page:
Better business alignment with straightforward licensing and clarity of intellectual property ownership
[win2k]
The Microsoft licensing model does not contain licensing provisions that require an OEM, and potentially its licensees, to disclose the source code for its intellectual property in a widespread fashion to open source participants. An OEM building a server appliance with Windows 2000 Server operating systems and the SAK has the assurance the software code and added value it develops remain the OEM's intellectual property.
[linux]
To ensure proper management of its intellectual property rights, an OEM must carefully examine an array of licensing complexities around the General Public License (GPL) that govern Linux. These complexities have resulted in embedded and dedicated operating system companies such as Wind River saying that they are seeing "a growing problem due to the growing uncertainty of using GPL-based code in embedded devices". An example of this risk can be taken from NVIDIA. An NVIDIA programmer, in the course of developing a driver for one of its products, used a portion of code from a freely available video driver. The developer failed to realize the code was licensed under the GPL and would therefore require NVIDIA to release the source code for its entire driver. Because NVIDIA did not want to release the source code to its commercial software, the company incurred substantial cost to develop a new driver that did not contain the GPL code.
Companies need to recognize that in embedded and dedicated devices, such as server appliances, significant gray areas exist in the implications of the GPL's terms. Some forms of code linking and commingling may or may not trigger legal obligations under the GPL. As Michael Scott and Michael Krieger, a lawyer and computer science professor respectively, recently wrote, "Rare is the month when a lawyer who specializes in technology does not have a new client asking for help in untangling an open source code problem".
Yeah, last time I checked if you use parts of or modify the GPL'd source code that comes with a linux distribution you have to give your product back to the community. When you use parts of or modify the source code that comes with windows, you....ummm.....
How about XPs modded into MPs?
No joke. It's an old (but very functional) tv so I'm not too worried about hurting its cosmetic appearance, and there really isn't that much information on the lower 9th of the screen anyway. Programs with scrolling headlines/stock tickers (i.e. news) are a _lot_ more watchable when my eyes aren't constantly being sucked to the bottom the screen. Same thing for shows with network promos, like star trek on TNN. They vertically squish the picture instead of replacing part of it so there's literally nothing missing. I had no idea how much those distractions were interfering with my viewing until I got rid of them.
Personally, I'm very pleased with the results. Of course, I don't watch a great deal of TV and I never use it with tv-out on my computer so this kind of thing may not be right for everyone.
have a standard installer? There's rpm, there's deb, there's pkg (or whatever slack uses), there's the ports system, and there are probably more. I agree that the community could benefit greatly from more standardization. I just don't think we have it yet.
This kind of technology has already been implemented in many gnutella clients. Gnucleus (my favorite one) can be configured to use random ports.
I was was working on a custom tailored compression algorithm for gnutella search traffic that would reduce search network traffic bandwidth usage to (a rough guess) 20% of what it is now, but that got shelved for a while when real life (tm) suddenly became a priority. I will undoubtedly resume work on it soon, but while I was toying with a few different ideas regarding the gnutella protocol I came up with an idea for a completely unrecognisable (from the ISP's point of view) communication system for p2p. Briefly:
Step 1: Use the current system of random port assignments using gping/gpong/GWebCache to spread node data.
Step 2: Upon connecting to another node, before any handshaking of any kind is done, exchange public keys (generated by each instance of the node software upon install) and use them to set up an OpenPGP compliant encrypted tunnel.
Step 3: Use the standard gnutella three way handshake to exchange node data and negotiate options (e.g. QRP support, compression, etc...)
Step 4: Begin normal network operations.
It's undetectable because there is no distinguishable pattern even if the ISP decides to sniff packets.
-The ports and IP addresses are random.
-The first 2 kbits (or whatever length) of the connection are random (public keys would be generated randomly by the node software on install). Especially paranoid nodes could generate a new key pair for each connection.
-All the data following that would be encrypted (random).
Since everything (IPs, ports, data) would be random (not to mention protected from snoops!) ISPs would have no way of blocking it. Their only option would be to execute a man in the middle attack, but that would require modifying the data stream which, while undetectable & successful in the event that the connection in question is in fact a gnutella connection, would really confuse anything else.
In short, an ISP would not be able to check a connection without destroying it in the case that it's not p2p.
I don't think their actions have anything to do with copyright or piracy. Think about it: if a cable company has a node serving a neighborhood through a single coax loop providing 30Mbit of shared bandwidth with each user being able to snag up to 3Mbit downstream (the situation where I live), and there are just three people on the loop who are downloading 24/7 using some fastrack servent, then nearly a third of their bandwidth capacity is being used by three people.
9 9999999% of all activity on the fastrack network violates copyright. Users have no means of legal retaliation.
They're not blocking fastrack for copyright/piracy reasons. They're doing it because fastrack users consume a _lot_ of bandwidth and internet service provider business models are completely and utterly dependent on customers that don't fully use what they pay for. In the same way that modem ISPs never have enough modems for every customer to dial in at once, cable ISPs never have enough bandwidth for every customer to download (at full speed) at once. They blocked fastrack because:
-Blocking it frees up a _whole lot_ of bandwidth. That bandwidth can then be oversold to many more customers, increasing revenue without having to increase network capacity.
-99.9999999999999999999999999999999999
-It's used by relatively few people. Blocking port 21 (ftp) would cause an uproar. Blocking port 1214 (fastrack network search traffic) caused only the tiniest of squeaks.
I'd say there's a difference there. People want good web browsers, people want good office suites, people want journaling file systems. Sure, the average user may not know what a journaling file system is, but he sure doesn't want to have to deal with fixing the file system after a crash or power outage, which is basically the same thing.
"People" don't want DRM.
Average users don't want it because it restricts their abitily to use information tools and toys like computers and portable music players. Deveopers don't want it because "perfect" DRM is just plain impossible to code. Information philosophers don't want it because they understand that the core ideas behind DRM (the "renting", "expiring", and "control" of information in the posession of untrusted parties) go against the fundamental laws of the "physics of information". Economists who understand what's going on don't want it because they don't want to see huge pieces of the economy resting upon a cracked (har har) foundation.
Large media-based corporations want it because they can use it to fatten their wallets and they can get away with it because joe average doesn't know enough to be able (or willing) to put up a fight.
A large media-based corporation controls windows and is influenced by other large media-based corporations. Developers control linux, and are influenced by insightful information philosophers and technologically astute economists, none of whom are saying "Linux has no good Digital Rights Management!"
Actually, I think there's another important issue here. If the MPAA sends out a search packet containing "star wars episode II" and your computer responded with a search hit packet saying "I have that! Here's a list of hits to your search that I have on my computer." then did they really enter your computer without your permission? Setting aside the debate as to whether it's "right" for the MPAA to do this or even operate their business under current copyright law, this brings up an interesting question.
Isn't that the digital analogue (har har) of the MPAA calling you up on the phone and asking "Do you have a pirated copy of Star Wars Episode II: Attack of The Clones?" and you replying "Sure do! If you want a copy, send me a self addressed stamped envelope big enough for two cds."? I certainly wouldn't consider _that_ situation an invasion of privacy.
Of course, law, information, and copyright operate differently in the realm of computers and the internet. You can even sign a binding contract that holds up in court simply by hitting the tab key a few times on your computer and then pressing the enter key (choosing "I Agree" after a EULA).
In my IRC days a lot of people would operate file servers, but upon connecting they would display a message to the effect of:
You may not download any file from this server or obtain any file listings. You must disconnect immediately! If you stay connected or interact with this server in any way other than disconnecting, you are violating the terms of the Internet Privacy Act signed into law by Bill Clinton in 1995 and will be guilty of a federal crime.
IANAL. I don't remember the text exactly. However, would something like this still work if the user's computer hit "I Agree" automatically or blocked the warning text from being displayed?
If so, then couldn't all p2p packets carry a disclaimer such as this one to prevent "unauthorized" usage by the *AA? If not, then where do you draw the line between a user's action and a computer's action? After all, when you click I agree, isn't it _Windows_ that sent the WM_LEFTCLICK (or whatever) message to the window causing the software to install?
A few years back the search engine metacrawer ("Search the search engines!") set up a service called "metaspy" that showed search queries which were being processed. Aparently they didn't want to get into any trouble by exposing kids to uncensored searches, so they set up two viewing modes, each with an icon. The "clean" version's icon is a typical sleuth character in green holding a magnifying glass and a pipe; this was the old metaspy icon. The new "metaspy exposed" icon for unfiltered search viewing also features a typical sleuth character, but one whose trenchcoat is open and is clearly not wearing and pants.
I'm not sure how ati's maxx technology was supposed to work, but having spent a lot of time drooling over 3dfx cards in my gaming days I think I can shed some light on the subject.
The voodoo 2s (like the original voodoo graphics) used a pass-though cable to add 3d support to an existing machine. A cable would come out of the 2d card and go directly into the voodoo 2. A cable would then connect the voodoo 2 to the display device. The voodoo 2 was the first 3dfx card to support SLI, scan line interleave, where one card would render the even scan lines and the other would render the odd ones. The speed was about equal to a voodoo 3 2000, and resolution was limited to a max of 1024x768. This configuration was only obtainable by adding another voodoo 2 pci card of the same brand and memory configuration and connecting them with a special cable.
The voodoo 3 was not capable of doing SLI. Although SLI was a very popular option with gamers, the voodoo 3 did not have support for it, largely because it was more of an improved banshee (technology-wise) than a voodoo 2. 3dfx chose to use the 'voodoo' name in order to associate it with the successful voodoo line rather than the banshee card which was, for lack of a better word, an utter failure.
The voodoo 4 could not do SLI either. While it used 3dfx's VSA 100 chip which was capable of doing SLI, the defining characteristic of the voodoo 4 card was that it had only one gpu.
SLI was brought back with the voodoo 5. Instead of returning to the multiple-card-voodoo-2 method of doing SLI, 3dfx chose to put all of the chips on the same board. The voodoo 5 5500 had two VSA 100s, whereas the voodoo 5 6000 had four.
That's the deal with 3dfx.
Regarding MAXX technology conflicting with NT kernel based OSs, I don't think it would just becase it supported SLI. One of my friends is using a voodoo 5 5500 card with windows 2000 right now, and he hasn't had any problems. However, that doesn't rule out problems with other parts of the MAXX architecture.
you can put that memory bandwidth to good use. Normally, the asus board , using the via kt333 chipset, runs the fsb at 133MHz DDR and the memory bus at 166MHz DDR (if you have PC2700 memory). In order to get that extra memory bandwidth to the cpu, you have to increase the fsb clock to 166MHz DDR. If you're not into overclocking you cpu 25%, then you have to lower the clock mulitplier to compensate. The asus board offers a 1/5 clock divider for your pci bus so all your other devices can run in spec. Have fun :).
P.S. The MHz stuff.
MHz only means millions of cycles per second. Exactly what that means depends on how you define "cycle". If you're using the accepted definition of a cycle, in terms of memory, then you're talking about a cycle bounded by the event which occurs every time your bus does this:
_
/ \_/
(I'm not the best ascii artist but you get the idea) and the memory bus operates at 166MHz. However, if you're calling a cycle the event that occurs every time the bus can put a bit on a data line, then the memory bus operates at 333MHz. Either way, you're still going to get a maximum throughput of 2.7GB/s.
P.P.S.
If you want to change your fsb from 133MHz to 166MHz then you have to get a cpu with a rated frequency into which 166 will divide nicely. That means the XP 2000+ (1666MHz) or the XP 1500+ (1333MHz). If you get any other processor, you'll have to overclock or underclock a little since the cpu multiplier can only be set to multiples of 1/2.
...than is immediately evident. After listening to it a few times I can actually remember the acronym CBDTPA.
Thought provoking idea. How about a system where a value of X dollars is declared for a certain piece of "intellectual property" when it is copyrighted/patented. %1 of X per year is paid in taxes. After the owner of that piece intellectual propery gains X dollars in income from its licensing, the work becomes public domain. X could be adjusted at any time to allow the copyright holder to retain ownership of the work, but that entity would have to pay "back taxes."
It works because:
-Entities are encouraged to produce works that are of high value to the public.
-Writers of free software (beer or speech) can retain their rights indefinitely as long as they don't charge for it, but can still accept donations.
-Passing the 1% tax on to consumers would just cause the work to pass into public domain faster.
Good idea? Terribly flawed?
What do you think?