if the price they sell broadband at is $29.95/month, but they will only sell line access to the competing ISP at $39.95/month, the ISP cannot compete.
Don't they already do this? (Verizon DSL prices vs Easystreet DSL prices) Easystreet's Verizon line charge is more expensive than buying DSL straight from Verizon, with one year contract. Are these numbers accurate, or am I missing something here?
That's a cool system, though from their test site it looks like it could use a bit of interface work. I hope an improved form makes it into mediawiki.
It might be interesting to use a rating system in conjunction with an automated system to determine importance (based on either traffic statistics or a computation of pagerank based on the link graph of the wiki). That would allow users to find pages with high importance but low quality.
When an article goes unedited for maybe 4 hours it automatically becomes stable.
Not a bad idea, but maybe it could be based on page views instead of time. If a draft has been read a certain number of times without a modification, it could be moved to stable. Four hours may be too short in the early morning, or too long for current events.
Either way, there's a significant danger of a troll getting their edit into the stable version, then editing the draft frequently enough to prevent it from stablizing, thus preventing other users from fixing the edit. For that reason, I prefer a voting process. To make it resilient against targetted trolling, perhaps the articles each user can vote on should be selected at random, much like metamoderation here on slashdot.
But would the users change over drafts to stable, or would the editors?
Good question, I don't know what the best solution would be. Perhaps draft pages could be periodically placed in a vote queue, which users could periodically visit and vote each draft up or down. (Preferrably, voters would be presented with a draft in which changes from the original are highlighted.) If a draft passes voting, it replaces the "stable" article.
For some idea of how this can work, head over to kuro5hin and sign up for an account. All their articles go through a community voting process, which mostly works (though the trolls seem to make up a significant minority of the voting users - this would undoubtedly be a problem for wikipedia as well).
If there are too many drafts in the voting queue, it could be split by topic into multiple queues, or users could be presented with a random subset of drafts.
I have no idea how they plan on implementing this, but if it was up to me, I'd have a "stable" and "draft" version of each high-profile page. Anyone should be able to edit the draft. Periodically, the draft version could replace the stable version (perhaps a voting system could be in place, not unlike the kuro5hin submission queue).
The importance of a page (to decide if a locked "stable" page is necessary) could be determined automatically either by number of hits, or computing the pagerank of each page given the link graph of the whole wiki.
I vaguely remember that every antenna used for transmission in that range (2.4Ghz included) is supposed to be FCC approved and not modified
That's true for anything mass produced, but there is an exception for homemade devices:
Sec. 15.23 Home-built devices.
Equipment authorization is not required for devices that are not
marketed, are not constructed from a kit, and are built in quantities of
five or less for personal use.
It is recognized that the individual builder of home-built
equipment may not possess the means to perform the measurements for
determining compliance with the regulations. In this case, the builder
is expected to employ good engineering practices to meet the specified
technical standards to the greatest extent practicable. The provisions
of Sec. 15.5 apply to this equipment.
Perhaps by itself it is nothing but a container for storing pringles, but it becomes a part 15 device when it's connected to an appropriate transciever.
Equipment authorization is not required for devices that are not
marketed, are not constructed from a kit, and are built in quantities of
five or less for personal use.
It is recognized that the individual builder of home-built
equipment may not possess the means to perform the measurements for
determining compliance with the regulations. In this case, the builder
is expected to employ good engineering practices to meet the specified
technical standards to the greatest extent practicable. The provisions
of Sec. 15.5 apply to this equipment.
Connect a tightly directional antenna to a transmitter that's operating at full power meant for omnidirectional use, and you'll have an illegal setup. That's exactly the situation most canttenas find themselves in.
The limit for part 15 devices is 1 watt (30 dbm) absolute power or 4 watts (36 dbm) effective radiated power (EIRP). Most wireless cards are around 35 milliwatts (~15 dbm), and are well within the absolute limit. EIRP is measured as transmit power+gain, so a 15 dbm wireless card connected to a 12 dbi cantenna gives us 27 dbm EIRP, about 1/10th the legal EIRP limit. (Note: this is for point-to-multipoint communication. The gain restriction is much looser for point-to-point setups.)
Those who use high power cards (200 milliwatt (~23 dbm) wireless cards are available) may be close to or over the limit, but I doubt they represent a majority of cantenna deployments.
Homemade antennas are permissible according to part 15 section 23 (subject to a few restrictions).
Equipment authorization is not required for devices that are not
marketed, are not constructed from a kit, and are built in quantities of
five or less for personal use.
It is recognized that the individual builder of home-built
equipment may not possess the means to perform the measurements for
determining compliance with the regulations. In this case, the builder
is expected to employ good engineering practices to meet the specified
technical standards to the greatest extent practicable. The provisions
of Sec. 15.5 apply to this equipment.
Also, cantennas are no better (except in terms of price) than commercially available antennas which are also legal to own and use, provided you use them in accordance with fcc regulations, for instance by not exceeding power and gain limits, and without breaking any other applicable laws.
(disclaimer: I am not a lawyer, or an RF engineer)
Apache's httpd is trivial to configure and maintain, both build process and config being very well documented.
The article pointed out a number of inconsistencies in the config file syntax, many of which are complained about by real users on a regular basis. The author of the article is doing the apache project a service by drawing attention to these problems in the hopes that they might actually get fixed.
If someone is running their own server, you expect a modicum of technical knowledge and aptitiude.
That elitist attitude is preventing some otherwise good tools from being more widely adopted.
As someone who occasionally to set up a web server, I find apache's config file somewhat confusing (mostly due to its large size). It could be a lot worse, but it could be a bit better too. Serving web pages is really a simple task, why should setting it up be any harder than absolutely necessary?
More people who complain loudly when something doesn't work the way it should. I applaud Rich Bowen for this honest critique of Apache configuration, and I hope more people do the same for their favorite open source projects. Sometimes, that's the only way things get fixed.
I'm also a big fan of the "Grumpy Editor's Guide" series of articles at Linux Weekly News.
Not at all. My understanding is that the video game developers are required to submit footage from the game that is representative of the maximum level of offensive content the player is going to experience, and the ESRB rates the game based on submitted footage. If the developer doesn't disclose some content that is more offensive than what they submitted to the ESRB, it's their own fault. I'm not sure what the penalty is for such a lapse.
Autopackages will back up any file they overwrite rather than just erasing it, like RPM would (the conflict detection only works if everything is installed via RPM, which often isn't the case).
No doubt this is true in the common case. I'm more concerned with someone distributing an autopackage file that isn't really an autopackage file.
Obviously the package scripts would not be in charge of verifying their own authenticity, that'd be a dumb design. The launcher application which is associated with.package files would do that, and only pass control to the package itself once verified. That's no different to RPMs which can contain arbitrary scriptlets.
The launcher application is the.package file itself: instructions to install an autopackage file are to set it executable and then run it. That process includes no sanity checks whatsoever.
RPM provides no security. They must always be run as root, and can run any program or software they like, at root privileges. There is no functional difference between an RPM and an executable binary: they can both do whatever they like
Rpm may be invoked with the "--noscripts" option. Most normal packages should install just fine this way. Rpm may not be perfectly secure in the sense that a bad package might install malware, but at least you can verify what it did install (if you use --noscripts), and rpm makes sure it doesn't clobber the files of an existing package. Also, rpm will check that the package is cryptographically signed by a trusted source.
Autopackage has at least four different mechanisms for dealing with dependencies, including static linking, bundle linking, weak linking and a dependency resolver, why don't you read up on it instead of bashing it? All of your issues are covered in the FAQ.
Ok, so if it isn't installed and isn't part of the current package, it'll grab another package from somewhere else. Or something. Where it gets the package from is not explained in the faq, but I'll assume it can download it from some repository like yum.
Autopackages aren't really ad-hoc installers, they're actually a hybrid of RPM style packages and wizard-style installers, combining the best elements of both. They understand dependencies, are low overhead, are built from specfiles and have a consistent and integrated user interface. Nonetheless, (when done well) they are easy to use and look professional. I fail to see how this is a step backwards given the reality that not everybody uses the same distribution.
It's a step backwards because it gives users a gun with which to shoot themselves in the foot. The main problem I see is that the.package files are executable. Regardless of how well autopackage works, sooner or later, some user is going to download a.package file and execute it and it won't be a real.package file, it'll be malware. I don't think rpm is a perfect system either, but it will at least do some reasonable sanity checks before installing anything.
The design of autopackage may be quite good, but I think that if you take away the "feature" that it doesn't require any pre-existing package management system (which I don't see as a feature at all), it doesn't do much that rpm can't do, and it doesn't do a lot of the things that rpm and yum can do, such as auto-update and package signature verification.
I realize that not everyone is going to agree with me on this, but I think autopackage sacrifices too much security in the name of convenience.
I'm not aware of any mechanism that rpm or yum has to automatically detect 'tampering' of already-installed files (such as through a worm or virus).
There's an obscure rpm command (I don't remember it off the top of my head) to check whether any of the installed files have changed since installation. More importantly, rpm will generate an error if a new package overwrites or changes files in an existing package. (There may be ways around this (I don't know much about the internal format of rpms), but in most cases it isn't necessary to let packages have their way with the filesystem, and rpm should at least generate a warning before running any scripts. If it doesn't, I'd consider that a bug.)
...Then if the package isn't from a 'trusted source' than a dialogue would pop up to warn the user of potential danger associated with installing this package.
The problem here (and my main objection with autopackage) is that autopackage files are, as far as I can tell, just regular executable that could contain absolutely anything without any kind of sanity checking. How hard do you really think it would be to write a program that looks and acts like a.package file, but doesn't bother to do the check you suggest or pop up a warning? Do you really think it's the package's responsibility to verify its own authenticity? By comparison, rpm files are typically digitally signed by some distributor, and the administrator of the machine can select which distributors to trust by installing public keys for those distributors.
You can double click a rpm file and have it install itself, but it requires the root password to do so, and it doesn't handle dependencies like autopackage does.
Actually, now that I think about it, treating rpms like executables is a bad idea, since someone could easily write a foo.rpm package that was really just a regular executable in disguise and bypass any sanity checking that rpm might do. Better to treat it as what it is: a data file that should be opened by the appropriate application.
As for requiring the root password, I think this is one area where rpm could be improved. As far as I know, there's no way to install a program or library from a standard rpm into your own home directory.
As for handling dependencies, what does autopackage do? Ship with all of the dependencies in one big package? Seems kind of wasteful if most of those are already installed on the target system (though I'll concede that sometimes you just want a thing to work, regardless of wasted disk and/or bandwidth). Yum handles dependencies quite nicely, as long as it can find them in one of its repositories.
I can see how some people might like autopackage, but to me it seems like a step backwards. The interest in the project is perhaps indicative of the weaknesses of rpm and yum (confusing documentation, sluggish performance, difficult configuration). I'd rather see yum made better than to abandon package maneagement altogether and go back to using ad-hoc installers that might or might not do the right thing.
One of the biggest problems autopackage has is simply that developers don't know about it.
I disagree. I think the real problem is that many developers, administrators, and users don't like the idea of trusting an application to install itself correctly on a system. There's no automatic way to be sure the program hasn't been tampered with, no way to ensure that security updates get installed according to the preferred update policy, no way to ensure the installer won't clobber existing files or install spyware or a rootkit, and no way to ensure the uninstaller will even work.
If rpm/yum is percieved to be harder to use than a gui installer, it's because the interface and/or documentation is bad and should be fixed (perhaps rpms should be treated like executables, and running "./foo.rpm" should be equivalent to "rpm -i foo.rpm") and configuration is unnecessarily difficult. Conceptually, installing an rpm should be easier than running a gui installer because it doesn't ask any questions.
I assure you that we DO NOT have the ability to model a large number of objects around L1. We certainly could create this capability, but you are talking worse-than-realtime calculation times in our current state of technology (for many-multiple objects that aren't allowed to collide). The problem is already 'intractable' in the sense that it is multi-body dynamics -- no solution, must model via iteration.
I didn't think about the objects exerting gravity on each other. I'll concede that that might complicate things greatly, but only if the forces involved exceed the maneuvering capability of the objects. (They need not expend fuel to move if they are effectively large solar sails and they have the sophistication to change shape to maneuver themselves wherever they want to go.)
I agree: it could be done. Iff we needed it....Technology like this *is* fun to consider:~)
Yeah, we'd be better off working on more realistic projects, but thinking about really hard problems from time to time can be worthwhile, if for no other reason than to remind ourselves of how hard they really are. (Reducing carbon emissions sounds so much easier by comparison.)
That's why our solar observatory at L1 is in "orbit" around L1 rather than being in it.
No, actually SOHO is in orbit around L1 so that it isn't in front of the sun from Earth. This makes communication much easier (less background noise). Its orbit is unstable, and it compensates with thrusters. In 1998, they lost control of the craft for three months and it managed to not fall into the sun or back to earth, so I don't suppose the L1 instability is much of a problem as long as there is some way to correct its position once in a while.
once it STARTS going away from the point of equilibrium, it continues to do so at an accelerating rate
So, as long as you don't wander too far from the point of equilibrium, it shouldn't take much effort to remain there.
The amount of solar pressure would be incredible on an object large enough to do anything; as would the size. Movable anything would be nigh impossible.
If that's really a problem, then use a large number of smaller objects in orbit around L1. (SOHO does this already, so you can't tell me its impossible.)
Also, I think that the Sun-Earth L1 is so far out there that it is completely pointless to consider trying to 'block' anything from there. I don't know where the 'ideal' (focal?) point would be, so I could easily be wrong here.
L1 is about 1% of the distance from the earth to the sun (~1.5 million km vs ~150 million km). The sun has a radius of about.7 million km, the earth has a radius of about 6000 km. If I did the math right, I believe a small object at L1 would cast a (diffuse) shadow who's penumbra is a little bit bigger than the earth, so some small portion of the shadow would be wasted. The interesting question is whether the extra energy needed to lift an object into L1 (as opposed to low earth orbit) is worth the increased coverage of its shadow. (Of course, a solar sail powered craft could plausibly maneuver itself to L1 without any greater lifting expense than what it takes to hoist it into low earth orbit.)
As a whole, the idea is pretty high on the list of stupidest F#$^&ing things I've ever heard presented as serious considerations. (Not your statement, the idea of blocking the sun instead of cleaning up our act.)
Yeah, it's probably pretty dumb, but we should at least do some sort of informed cost/benefit analysis before discarding it completely. Also, if we can ever get a space elevator going, that cost/benefit analysis is going to change by quite a lot.
It seems to me that the stationkeeping problem could be resolved with large moveable surfaces. If it's getting pulled into the earth, the occluding objet could decrease its silouette to get pulled back towards the sun, or if it's too close to the sun, it could increase its silouette to get pushed back towards earth. If the object is shaped like a fan, the tilt of the blades could be used to induce spin (useful if it is a non-rigid structure). Energy to actuate the moveable parts could come from solar panels, and the thing could be controlled by a simple computer.
Slashdot Mirror
Don't they already do this? (Verizon DSL prices vs Easystreet DSL prices) Easystreet's Verizon line charge is more expensive than buying DSL straight from Verizon, with one year contract. Are these numbers accurate, or am I missing something here?
That's a cool system, though from their test site it looks like it could use a bit of interface work. I hope an improved form makes it into mediawiki.
It might be interesting to use a rating system in conjunction with an automated system to determine importance (based on either traffic statistics or a computation of pagerank based on the link graph of the wiki). That would allow users to find pages with high importance but low quality.
Not a bad idea, but maybe it could be based on page views instead of time. If a draft has been read a certain number of times without a modification, it could be moved to stable. Four hours may be too short in the early morning, or too long for current events.
Either way, there's a significant danger of a troll getting their edit into the stable version, then editing the draft frequently enough to prevent it from stablizing, thus preventing other users from fixing the edit. For that reason, I prefer a voting process. To make it resilient against targetted trolling, perhaps the articles each user can vote on should be selected at random, much like metamoderation here on slashdot.
Good question, I don't know what the best solution would be. Perhaps draft pages could be periodically placed in a vote queue, which users could periodically visit and vote each draft up or down. (Preferrably, voters would be presented with a draft in which changes from the original are highlighted.) If a draft passes voting, it replaces the "stable" article.
For some idea of how this can work, head over to kuro5hin and sign up for an account. All their articles go through a community voting process, which mostly works (though the trolls seem to make up a significant minority of the voting users - this would undoubtedly be a problem for wikipedia as well).
If there are too many drafts in the voting queue, it could be split by topic into multiple queues, or users could be presented with a random subset of drafts.
I have no idea how they plan on implementing this, but if it was up to me, I'd have a "stable" and "draft" version of each high-profile page. Anyone should be able to edit the draft. Periodically, the draft version could replace the stable version (perhaps a voting system could be in place, not unlike the kuro5hin submission queue).
The importance of a page (to decide if a locked "stable" page is necessary) could be determined automatically either by number of hits, or computing the pagerank of each page given the link graph of the whole wiki.
That's true for anything mass produced, but there is an exception for homemade devices:
Homemade devices are permitted under part 15 rules under certain circumstances, and they don't need to be FCC certified prior to use.
Homemade devices are permitted under Part 15 section 23:
The limit for part 15 devices is 1 watt (30 dbm) absolute power or 4 watts (36 dbm) effective radiated power (EIRP). Most wireless cards are around 35 milliwatts (~15 dbm), and are well within the absolute limit. EIRP is measured as transmit power+gain, so a 15 dbm wireless card connected to a 12 dbi cantenna gives us 27 dbm EIRP, about 1/10th the legal EIRP limit. (Note: this is for point-to-multipoint communication. The gain restriction is much looser for point-to-point setups.)
Those who use high power cards (200 milliwatt (~23 dbm) wireless cards are available) may be close to or over the limit, but I doubt they represent a majority of cantenna deployments.
Homemade antennas are permissible according to part 15 section 23 (subject to a few restrictions).
Lozito, meet fcc part 15 rules:
Also, cantennas are no better (except in terms of price) than commercially available antennas which are also legal to own and use, provided you use them in accordance with fcc regulations, for instance by not exceeding power and gain limits, and without breaking any other applicable laws.
(disclaimer: I am not a lawyer, or an RF engineer)
That elitist attitude is preventing some otherwise good tools from being more widely adopted.
As someone who occasionally to set up a web server, I find apache's config file somewhat confusing (mostly due to its large size). It could be a lot worse, but it could be a bit better too. Serving web pages is really a simple task, why should setting it up be any harder than absolutely necessary?
I'm also a big fan of the "Grumpy Editor's Guide" series of articles at Linux Weekly News.
If SGI closes its doors, what impact will that have on OpenGL?
No doubt this is true in the common case. I'm more concerned with someone distributing an autopackage file that isn't really an autopackage file.
The launcher application is the .package file itself: instructions to install an autopackage file are to set it executable and then run it. That process includes no sanity checks whatsoever.
Rpm may be invoked with the "--noscripts" option. Most normal packages should install just fine this way. Rpm may not be perfectly secure in the sense that a bad package might install malware, but at least you can verify what it did install (if you use --noscripts), and rpm makes sure it doesn't clobber the files of an existing package. Also, rpm will check that the package is cryptographically signed by a trusted source.
Ok, so if it isn't installed and isn't part of the current package, it'll grab another package from somewhere else. Or something. Where it gets the package from is not explained in the faq, but I'll assume it can download it from some repository like yum.
It's a step backwards because it gives users a gun with which to shoot themselves in the foot. The main problem I see is that the .package files are executable. Regardless of how well autopackage works, sooner or later, some user is going to download a .package file and execute it and it won't be a real .package file, it'll be malware. I don't think rpm is a perfect system either, but it will at least do some reasonable sanity checks before installing anything.
The design of autopackage may be quite good, but I think that if you take away the "feature" that it doesn't require any pre-existing package management system (which I don't see as a feature at all), it doesn't do much that rpm can't do, and it doesn't do a lot of the things that rpm and yum can do, such as auto-update and package signature verification.
I realize that not everyone is going to agree with me on this, but I think autopackage sacrifices too much security in the name of convenience.
Actually, now that I think about it, treating rpms like executables is a bad idea, since someone could easily write a foo.rpm package that was really just a regular executable in disguise and bypass any sanity checking that rpm might do. Better to treat it as what it is: a data file that should be opened by the appropriate application.
As for requiring the root password, I think this is one area where rpm could be improved. As far as I know, there's no way to install a program or library from a standard rpm into your own home directory.
As for handling dependencies, what does autopackage do? Ship with all of the dependencies in one big package? Seems kind of wasteful if most of those are already installed on the target system (though I'll concede that sometimes you just want a thing to work, regardless of wasted disk and/or bandwidth). Yum handles dependencies quite nicely, as long as it can find them in one of its repositories.
I can see how some people might like autopackage, but to me it seems like a step backwards. The interest in the project is perhaps indicative of the weaknesses of rpm and yum (confusing documentation, sluggish performance, difficult configuration). I'd rather see yum made better than to abandon package maneagement altogether and go back to using ad-hoc installers that might or might not do the right thing.
I disagree. I think the real problem is that many developers, administrators, and users don't like the idea of trusting an application to install itself correctly on a system. There's no automatic way to be sure the program hasn't been tampered with, no way to ensure that security updates get installed according to the preferred update policy, no way to ensure the installer won't clobber existing files or install spyware or a rootkit, and no way to ensure the uninstaller will even work.
If rpm/yum is percieved to be harder to use than a gui installer, it's because the interface and/or documentation is bad and should be fixed (perhaps rpms should be treated like executables, and running "./foo.rpm" should be equivalent to "rpm -i foo.rpm") and configuration is unnecessarily difficult. Conceptually, installing an rpm should be easier than running a gui installer because it doesn't ask any questions.
...to visit Japan!
Yeah, we'd be better off working on more realistic projects, but thinking about really hard problems from time to time can be worthwhile, if for no other reason than to remind ourselves of how hard they really are. (Reducing carbon emissions sounds so much easier by comparison.)
Lets see, 100 nanometers thickness times pi * 500km ^2 (1000km diameter is probably more than big enough) and we get... about 80,000 cubic meters.
Kapton film is 2 micrometers, that would give us a volume of... about 1.5 million cubic meters.
1/8 mm mylar gives us ...about 100 million cubic meters.
You're right, that is prohibitively big unless we can come up with some new materials and/or hoist bulky things into orbit with a space elevator.
So, as long as you don't wander too far from the point of equilibrium, it shouldn't take much effort to remain there.
If that's really a problem, then use a large number of smaller objects in orbit around L1. (SOHO does this already, so you can't tell me its impossible.)
L1 is about 1% of the distance from the earth to the sun (~1.5 million km vs ~150 million km). The sun has a radius of about .7 million km, the earth has a radius of about 6000 km. If I did the math right, I believe a small object at L1 would cast a (diffuse) shadow who's penumbra is a little bit bigger than the earth, so some small portion of the shadow would be wasted. The interesting question is whether the extra energy needed to lift an object into L1 (as opposed to low earth orbit) is worth the increased coverage of its shadow. (Of course, a solar sail powered craft could plausibly maneuver itself to L1 without any greater lifting expense than what it takes to hoist it into low earth orbit.)
Yeah, it's probably pretty dumb, but we should at least do some sort of informed cost/benefit analysis before discarding it completely. Also, if we can ever get a space elevator going, that cost/benefit analysis is going to change by quite a lot.
It seems to me that the stationkeeping problem could be resolved with large moveable surfaces. If it's getting pulled into the earth, the occluding objet could decrease its silouette to get pulled back towards the sun, or if it's too close to the sun, it could increase its silouette to get pushed back towards earth. If the object is shaped like a fan, the tilt of the blades could be used to induce spin (useful if it is a non-rigid structure). Energy to actuate the moveable parts could come from solar panels, and the thing could be controlled by a simple computer.