If you have packages with a package management system, then it's often
convenient to install under the one tree - the package manager can take care
for finding all the package's installed files at need (upgrade, delete, query
etc).
Under such a scheme usually the vendor gets to install in/usr/{bin,lib,...}
and third party packages tend to install in/usr/local/{usr,lib,...}.
For build-for-source it's often good to go your way, often installing in/opt/package-version/{bin,lib,...} and symlink to (say)/opt/bin for $PATH
convenience to users.
One often unstated advantage of the per-package tree approach,
aside form having everything in one spot,
is that you can install multiple versions of a package at a time
(or multiple different builds of the same package).
This can be used for testing bleeding edge releases without breaking
stuff, and of course for legacy support for other stuff that needs only
an older version of something.
Of course the system has pitfalls.
I run most of our "add on" software in the "per package dir in/opt"
fashion at my workplace, thus:
syncopt,
which scales mostly nicely for many workstations wanting this stuff.
Well, that's our fallback position. We much prefer things we can ssh/serial
port to. However, that's no good if you have to fiddle with the BIOS before
the machine boots. My nice Intel Server PC has a serial mode BIOS, but generally
PCs have video out and that's it. Most hostile.
What the poster (and myself, very much so) wants is a laptop that accepts
PC video/keyboard/mouse in.
Most desktop LCDs take video and convert for the LCD (which of course is very much digital, unlike CRTs which are fairly analogue).
I imagine most laptop LCD/video hardware might be digital straight through,
but the hardware for digitising video input must be very standard now.
Personally annoyed that my latest laptop lacks a serial port (it's on the port
expander - ugh) and has one of those annoying touchpads,
I remain,
The density of the rock has NOTHING to do with it (provided it's greater than that of the water of course - aside from pumice rock doesn't float). It's purely a volume calculation.
I would personally not care to receive an e-mail after two years from someone who wants to ask me something about a post that would be obsolete by then.
Plenty of posts don't become "obsolete".
If your posts are so time sensitive put an Expires: header
on them. At least there'll be a clue.
You'll get spam anyway.
Censoring one archive (eg Goole's) won't change that
and even if there were no public archives
you'd be getting spam because you've posted in a public space,
and presumably been seen.
Should I infer from your remark:
"in return I get reminded everyday by spam"
that you have good stats on which of your spams come from usenet archive harvesting?
Well just looking at the metamoderation email in my inbox that just arrived saying "Moderation Rated As Unfair", apparently I did. I remember reading the comment and don't
really recall moderating it, but certainly didn't think it
was flamebait. Maybe my mouse twitched while reaching for "insightful"?
Anyway, I quite agree that it's not flamebait and apologise for
my ineptitude.
Fortunately it seems that replying will undo my moderations!
So this apology should also serve to fix things:-)
Well the core issue is that the creator's motivations regarding use/monopoly etc
are "valid" in that they created the work and might arguably be entitled to oversee
its use.
The standard middlemen who obtain complete ownership of IP
have totally different motivations because
they are inherently parasitic in their activities.
This fundamental difference in motivation is the core of the abuse situation.
Dunno about unions, but the owner-vs-creator thing is right on the money.
This is why, IMO, copyright (and likewise patents - any IP "right")
should not be transferable from the creator.
Let them license it any way they see fit
(excepting perhaps a perpetual exclusive license, which is just ownership
rephrased)
but leave the ownership with the creator.
Even for a poll at hourly intervals this should get staggered across an given hour according to when the client starts. Also, a client should probably not be polling every 3600 seconds (or whatever interval) but
polling with a 3600 second gap between end of one poll and start of the next.
In this way a loaded server will smear the clients out simply by having slower
response, and the load will even out on its own.
It's always bad to have lots of agents doing things in synchrony
when that involves an outside resource.
Contact the client authors, give them a clue,
let the upgrades push the bugfix out.
Finally, isn't RSS done over HTTP anyway? So why aren't these clients going through
their ISP's proxy and doing Get-If-Modified? The target server should see
only a fraction of the spike even with bad clients. Unless they're very very bad...
None of these things is a direct flaw in RSS, just crap quality of implementation
in RSS clients.
Yeah, and it's their office design too. And by your logic we shouldn't be having this discussion (what's a good office design) as all because it's _their_ design. I'm a sysadmin. We vigorously oppose fascist network policies; not because they're a pain to police/install, but because having happy and conscientious staff is much more productive than having oppressed slaves. Our policies are sufficient to achieve the security level we want, and No More.
A large cost in launch vehicles is lugging their own propellant. Very very wasteful. A back of the envelope scribble for 300km against Earth surface gravity (9.8m/s2) shows that an initial speed of 2.5km/s should do it.
They're getting that for their rail guns (admittedly with small projectiles).
Obviously the acceleration needs scaling down (== longer launch path, eg up a convenient mountain) and the power requirements scale directly with mass for a
given laugh velocity.
Shouldn't this be a real contender for unmanned satellite deployment?
The velocities are there and you don't have to waste payload mass on launch propellant.
Oh please. So the French sell arms. So does the US. In fact, isn't the US the largest arms seller in the world? You imagine that only the Good Guys buy
these arms?
Depends: such a scenario requires self-replicating nanobots (of course, one might use the immune system's facilities for this and just piggyback its
recognition programs...), a step up from general junk a nanofactory might make
which will probably be just nanofactured dumb matter.
However, "root kits" for your scenario would neatly solve the Fermi paradox.
If we're anything to go by, naturally evolved top-of-the-food-chain folks
like us are too vicious and selfish to survive such power.
Can't remember where I came across this, but for entertainment:
Men are four:
He who knows and knows that he knows; he is wise, follow him.
He who knows and knows not that he knows; he is asleep, wake him.
He who knows not and knows that he knows not; he is ignorant, teach him.
He who knows not and knows not that he knows not; he is a fool, spurn him!
I'm sure it's coloured my attitude to supporting users:-)
And ISP filtering can readily be a PITA depending on the lists you read.
Example: I'm on several Yahoo lists. Naturally the odd virus (or virus-looking)
email gets onto one of the lists and (apparently) my ISP bounces it (even though I've got "no filtering please" chosen with them).
Anyway, the bounce is an SMTP 553 bounce. Yahoo considers this a "hard" bounce
(which it is) and TURNS OFF ALL MY YAHOO DELIVERY.
Very very very annoying.
Now, one side of this is that SMTP needs (and lacks) a "this particular
message will always be refused" error code.
That would work well for virus filters, since the delivering system (eg Yahoo)
could them just discard that message and continue with everything else.
The real fix is not to use these buggy mail clients. Like M$ LookOut!
And, though it's not applicable to the outright-buffer-overflow
viruses like this one, not to use systems with the vile design flaw of letting users
click on attachments and execute stuff.
For example, my mutt mail reader has a mailcap that drives its attachment
handling. Every clause runs a viewer.
If I get a.exe I get told its size or offered an opportunity to save it to disc. It does not offer or try to run it.
This core distinction is the weakness in the windows mail world:
no attachment should have executable power. An explicit user driven
install ritual should be needed to get such a thing into
a context where it can be run.
i.e. it should be a safe action for a user to double click
any attachment - that act should always invoke a viewer of some kind.
It is flamebait. Or you didn't read things. Frankly, I think both.
He asks for affordable or free software.
Professional DVD authoring stuff is/was quite expensive.
Whether that's justifiable is debatable,
but for the home-video DVD author expensive authoring software
for what's arguably a trivial commodity use is stupid.
He's asking what his choices are because his survey so far has not
turned up anything very swish.
Well that's a wake up to me. I though my old GPX600R was bad because
I had to drain the coolant just to change a spark plug. With a lot
of bikes you may have to pull the petrol ("gas") tank because that's
generally over the engine, but the GPX had a coolant hose obstructing things too.
However, your chevy remark makes me feel fortunate.
WRT the religious belief: some of that may stem from the fact that M$ may change the API or semantics behind it at whim. Aren't they famous for this? So unless you've followed their "preferred way" you are at greater chance of being screwed in the next change.
WRT to service packs, it depends what they break. There's plenty of dodgy free code out there
that might break if, say, glibc decides to adhere to some overlooked STDC requirement and there's plenty of other examples in this vein.
A busted update is one thing, but an update that exposes the brokenness of dependent code is quite another.
It seems to me that if this is to compensate copyright holders for piracy, it should follow directly that piracy is now perfectly legal because the holders are no longer uncompensated. Seems only fair.
For email, I categorise new stuff into many inboxes.
However, the stuff I keep I tend to stash in juts a few folders (out, saved, saved-web). To find random stuff I index it all with mairix (which is really good) and have a tiny shell script to run a mairix query and then pull up
the query results as a mail folder. It's very effective. Also, since when I reply to things I copy the source item to my "out" folder as well, I end up
with complete threads.
For non-email the problem is a bit harder. I categories roughly by workspace (home, work, friends) and then subtask. But I don't bother with crosslinks. There's any number of indexing tools on freshmeat for files.
You aware that you'll basicly drive users away from these sites? If I have to hop through an
ad to reach content I'll basicly just never come back. Likewise my policy with sites which are dysfunctional without JavaScript - I don't care if they're less pretty/funky without JS, but if they don't function at all then they lose my custom.
While TANSTAAFL is true in most contexts, the more offensive the ad (I'm talking degree of in-your-faceness, not "obscenity" or suchlike) the less value it has to the advertiser because it pisses potential customers off.
Come on people: vote with your mice! Have a few standards: _don't_ patronise sites whose practices offend you, _don't_ write web sites implementing ideas you despise (so many people seem to leave their consciences at home). If enough of us provide feedback this way the adverts can be driven back to the present-but-ignorable banner ad and the like. You don't have to provide email feedback to the site, just let it wither and die from your boycott.
That's the argument all right. How effective is this? Bugger all. The _publisher_ gets to make megabucks through posthumous sales (they own the copyright), or of course bury it as they do with most stuff.
And why is "creative work" considered special? Should my
dependents deserve to lose my income just because I die even though
I'm not making "IP"? Most would say yes. Why not authors etc? The logic's a big specious to me.
This is a sideline, but rather than revoking copyright (c)
altogether (which is hard to sell) why not change
the rules.
Suppose (c) remains always with the author(s) and
the legislation forbade distribution contracts
of more than, say, 2 to 5 years and contracts preventing the
author(s) from contracting with others for other works?
This would break the effective monopolies of today
without revoking author's desires for control. Likewise
with patents. much of the abuses prevalent today
stem from non-authors having (and keeping) control
over IP.
That's an interesting idea of "burden". This way
Joe Blow on the end of his cable modem can be secure from SYN flood. TO be sure, the downside
is a slightly more complex TCP stack, but 1) modern OSes will have encryption code handy as IPSec speads and 2) no metering is needed.
The drawbacks of your CISCO/router approach include 1) lots of state at the router 2) even if protecting the server behind the router from load, it will start discarding incoming legitimate connects, which makes the server's lack of load rather moot since nobody can get to it anyway.
Slashdot Mirror
Under such a scheme usually the vendor gets to install in /usr/{bin,lib,...}
and third party packages tend to install in /usr/local/{usr,lib,...}.
For build-for-source it's often good to go your way, often installing in /opt/package-version/{bin,lib,...} and symlink to (say) /opt/bin for $PATH
convenience to users.
One often unstated advantage of the per-package tree approach, aside form having everything in one spot, is that you can install multiple versions of a package at a time (or multiple different builds of the same package). This can be used for testing bleeding edge releases without breaking stuff, and of course for legacy support for other stuff that needs only an older version of something.
Of course the system has pitfalls. I run most of our "add on" software in the "per package dir in /opt"
fashion at my workplace, thus:
syncopt,
which scales mostly nicely for many workstations wanting this stuff.
Cheers,
What the poster (and myself, very much so) wants is a laptop that accepts PC video/keyboard/mouse in. Most desktop LCDs take video and convert for the LCD (which of course is very much digital, unlike CRTs which are fairly analogue). I imagine most laptop LCD/video hardware might be digital straight through, but the hardware for digitising video input must be very standard now.
Personally annoyed that my latest laptop lacks a serial port (it's on the port expander - ugh) and has one of those annoying touchpads, I remain,
The density of the rock has NOTHING to do with it (provided it's greater
than that of the water of course - aside from pumice rock doesn't float).
It's purely a volume calculation.
If your posts are so time sensitive put an Expires: header on them. At least there'll be a clue.
http://freshmeat.net/projects/x2vnc/
Drives a Windows display (that has a VNC service) from your X display.
http://freshmeat.net/projects/x2x/
Drives another X11 display from your X display.
Each may be attached to any edge of your main display and grab the mouse and
keyboard as it crosses that edge, then driving the other display.
Exactly what you asked for. Very Very Useful.
Anyway, I quite agree that it's not flamebait and apologise for my ineptitude.
Fortunately it seems that replying will undo my moderations! So this apology should also serve to fix things:-)
The standard middlemen who obtain complete ownership of IP have totally different motivations because they are inherently parasitic in their activities.
This fundamental difference in motivation is the core of the abuse situation.
Dunno about unions, but the owner-vs-creator thing is right on the money. This is why, IMO, copyright (and likewise patents - any IP "right") should not be transferable from the creator. Let them license it any way they see fit (excepting perhaps a perpetual exclusive license, which is just ownership rephrased) but leave the ownership with the creator.
Even for a poll at hourly intervals this should get staggered across an given hour according to when the client starts. Also, a client should probably not be polling every 3600 seconds (or whatever interval) but polling with a 3600 second gap between end of one poll and start of the next. In this way a loaded server will smear the clients out simply by having slower response, and the load will even out on its own.
It's always bad to have lots of agents doing things in synchrony when that involves an outside resource. Contact the client authors, give them a clue, let the upgrades push the bugfix out.
Finally, isn't RSS done over HTTP anyway? So why aren't these clients going through their ISP's proxy and doing Get-If-Modified? The target server should see only a fraction of the spike even with bad clients. Unless they're very very bad...
None of these things is a direct flaw in RSS, just crap quality of implementation in RSS clients.
Yeah, and it's their office design too. And by your logic we shouldn't be having this discussion (what's a good office design) as all because it's _their_ design. I'm a sysadmin. We vigorously oppose fascist network policies; not because they're a pain to police/install, but because having happy and conscientious staff is much more productive than having oppressed slaves. Our policies are sufficient to achieve the security level we want, and No More.
Obviously the acceleration needs scaling down (== longer launch path, eg up a convenient mountain) and the power requirements scale directly with mass for a given laugh velocity.
Shouldn't this be a real contender for unmanned satellite deployment? The velocities are there and you don't have to waste payload mass on launch propellant.
Oh please. So the French sell arms. So does the US. In fact, isn't the US the largest arms seller in the world? You imagine that only the Good Guys buy these arms?
However, "root kits" for your scenario would neatly solve the Fermi paradox. If we're anything to go by, naturally evolved top-of-the-food-chain folks like us are too vicious and selfish to survive such power.
Can't remember where I came across this, but for entertainment:
Men are four:
He who knows and knows that he knows; he is wise, follow him.
He who knows and knows not that he knows; he is asleep, wake him.
He who knows not and knows that he knows not; he is ignorant, teach him.
He who knows not and knows not that he knows not; he is a fool, spurn him!
I'm sure it's coloured my attitude to supporting users:-)
Now, one side of this is that SMTP needs (and lacks) a "this particular message will always be refused" error code. That would work well for virus filters, since the delivering system (eg Yahoo) could them just discard that message and continue with everything else.
The real fix is not to use these buggy mail clients. Like M$ LookOut!
And, though it's not applicable to the outright-buffer-overflow viruses like this one, not to use systems with the vile design flaw of letting users click on attachments and execute stuff. For example, my mutt mail reader has a mailcap that drives its attachment handling. Every clause runs a viewer. If I get a .exe I get told its size or offered an opportunity to save it to disc. It does not offer or try to run it.
This core distinction is the weakness in the windows mail world:
no attachment should have executable power. An explicit user driven
install ritual should be needed to get such a thing into
a context where it can be run.
i.e. it should be a safe action for a user to double click
any attachment - that act should always invoke a viewer of some kind.
He asks for affordable or free software. Professional DVD authoring stuff is/was quite expensive. Whether that's justifiable is debatable, but for the home-video DVD author expensive authoring software for what's arguably a trivial commodity use is stupid.
He's asking what his choices are because his survey so far has not turned up anything very swish.
However, your chevy remark makes me feel fortunate.
WRT to service packs, it depends what they break. There's plenty of dodgy free code out there that might break if, say, glibc decides to adhere to some overlooked STDC requirement and there's plenty of other examples in this vein. A busted update is one thing, but an update that exposes the brokenness of dependent code is quite another.
It seems to me that if this is to compensate copyright holders for piracy, it should follow directly that piracy is now perfectly legal because the holders are no longer uncompensated. Seems only fair.
Surely. DOS is a carriage _painted_ like a modern automobile.
For non-email the problem is a bit harder. I categories roughly by workspace (home, work, friends) and then subtask. But I don't bother with crosslinks. There's any number of indexing tools on freshmeat for files.
You aware that you'll basicly drive users away from these sites? If I have to hop through an
ad to reach content I'll basicly just never come back. Likewise my policy with sites which are dysfunctional without JavaScript - I don't care if they're less pretty/funky without JS, but if they don't function at all then they lose my custom.
While TANSTAAFL is true in most contexts, the more offensive the ad (I'm talking degree of in-your-faceness, not "obscenity" or suchlike) the less value it has to the advertiser because it pisses potential customers off.
Come on people: vote with your mice! Have a few standards: _don't_ patronise sites whose practices offend you, _don't_ write web sites implementing ideas you despise (so many people seem to leave their consciences at home). If enough of us provide feedback this way the adverts can be driven back to the present-but-ignorable banner ad and the like. You don't have to provide email feedback to the site, just let it wither and die from your boycott.
And why is "creative work" considered special? Should my dependents deserve to lose my income just because I die even though I'm not making "IP"? Most would say yes. Why not authors etc? The logic's a big specious to me.
Suppose (c) remains always with the author(s) and the legislation forbade distribution contracts of more than, say, 2 to 5 years and contracts preventing the author(s) from contracting with others for other works?
This would break the effective monopolies of today without revoking author's desires for control. Likewise with patents. much of the abuses prevalent today stem from non-authors having (and keeping) control over IP.
The drawbacks of your CISCO/router approach include 1) lots of state at the router 2) even if protecting the server behind the router from load, it will start discarding incoming legitimate connects, which makes the server's lack of load rather moot since nobody can get to it anyway.