get an arm. lcdarms.com makes some nice ones out of anodized machined aluminum. the space underneath is completely usable, and you can easily push the monitor off into the corner if you're reading or working with pen and paper.
congratulations for deciding you could use someone with experience to be around
go to the most challenging and difficult shop you can possibly. not a community college or a university. someplace where they write compilers for toy languages over a weekend. can spend an hour talking about the first 100 instructions after hard reset. someplace where they actually code instead of whinging about patterns
its very different for a service to filter connections than a backbone. the real threat to end-to-end and neutrality would be if transit providers start charging for traffic involving certain endpoints (which is how this discussion got started)
endpoints can make whatever restrictions they like, even if they are as idiotic as trying to get access providers to handle their sales and billing.
of course it would suck if i couldn't get internet access without also paying for some 'content plan', but thats a different issue entirely
just as aside, the great thing about the telnet/ssh switch is that for once, the new thing was even more scriptable and painless to use than what i used every day. i couldn't care less about the security implications, but really rsh was so retarted, and port forwarding so useful in the nacent age of fucking nats and firewalls, it made sense.
but in this case we have structural flaws, which as you point out have some workarounds..some of which have their own problems. it seems reasonable to think about other approaches. i'm not going to buy into the tablets brought down from the berkeley hills.
gnn isn't really advocating throwing out sockets, you'll have to blame chellechelle for the inflammatory headline. queue is exactly that, a forum for discussing practice, and not a very deep one at that.
go ahead and live with your select and poll variants, they really aren't that bad. but i dont think they are the best that can be imagined.
no. in fact i can remember having discussions myself about this more than 20 years ago, and those were hardly the first.
unix has these interfaces as a matter of historical accident, what was an excellent design at the time. its hardly the only good point in the space.
you might find that it helps to think about these thing..even when developing important, real-world applications. why shouldn't the kernel be able to call into userspace safely and transfer ownership of a buffer? is that really so terrible to consider?
if this were all in one domain, the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
because of the user kernel boundary we have a copy which is difficult to get around (put the next 1k bytes exactly here, although i really dont care), and some unfriendly and inefficient hacks to weasel around the 'natural' blocking semantics.
even if its completely academic, i think its interesting to look at the user kernel boundary and try to refactor things which have negative structural impacts.
15 years ago when i looked at the literature there were substantial problems with the efficiency of the selected routes, route convergence and message overhead. these things got much worse as the rate of change in the peer graph goes up.
ullman - datalog - 1989 plus or minus a couple years. strictly more powerful and quite a bit easier to program in. and substantially easier to process.
i've done a couple derived languages and they took months/weeks rather than the years the single sql-derived engine i worked on took.
i hardly want to defend sql, its a terribly conceived language.
however, if by 'distributability' you mean execution across machines connected by unreliable networks, then its just as straightforward to implement relations having a single key and a single value as multiple keys and multiple values. all the additional complexity is in the language front end, and its not that bad.
with both query semantics the primary limit in scaling, or concurrency, is the cost of providing isolation, if required, and the workload dependent serialization conflicts.
you're right. we should have some kind of place we can come together, present evidence, interpret the law, argue for both sides, and come up with a decision. presided over by someone deemed impartial , with alot of experience in the law.
Slashdot Mirror
get an arm. lcdarms.com makes some nice ones out of anodized machined aluminum. the space
underneath is completely usable, and you can easily push the monitor off into the corner if you're
reading or working with pen and paper.
congratulations for deciding you could use someone with experience to be around
go to the most challenging and difficult shop you can possibly. not a community college or a university.
someplace where they write compilers for toy languages over a weekend. can spend an hour talking about the
first 100 instructions after hard reset. someplace where they actually code instead of whinging about patterns
but these are *mega* clouds
yes, and you can have relational algebra without sql
so....the primary focus of this mission is checking out the trash we left 40 years ago?
can someone explain why fragmentation in the mapping between logical blocks and
physical addresses causes performance degradation?
is it an issue with logically sequential reads being spread across multiple pages?
a multi-level lookup to perform the mapping?
?
its very different for a service to filter connections than a backbone. the real threat to end-to-end and neutrality
would be if transit providers start charging for traffic involving certain endpoints (which is how this discussion
got started)
endpoints can make whatever restrictions they like, even if they are as idiotic as trying to get access providers
to handle their sales and billing.
of course it would suck if i couldn't get internet access without also paying for some 'content plan', but thats a
different issue entirely
unless you belong to an open source organization, it doesn't seem at all clear
that open source as a concept needs to maintain 'branding' at all.
zepher was perfectly useful before aim existed.
just as aside, the great thing about the telnet/ssh switch is that for once, the new thing was
even more scriptable and painless to use than what i used every day. i couldn't care less about
the security implications, but really rsh was so retarted, and port forwarding so useful
in the nacent age of fucking nats and firewalls, it made sense.
hardly. a random pile of scripts for poorly and inefficiently extracting packet fields?
what long term impact in the field of software?
but in this case we have structural flaws, which as you point out have some workarounds..some of which have their own problems. it seems reasonable to think about other approaches. i'm not going to buy into the tablets brought down from the berkeley hills.
gnn isn't really advocating throwing out sockets, you'll have to blame chellechelle for the inflammatory headline. queue is exactly that, a forum for discussing practice, and not a very deep one at that.
go ahead and live with your select and poll variants, they really aren't that bad. but i dont think they are the best that can be imagined.
no. in fact i can remember having discussions myself about this more than 20 years ago, and those were hardly the first.
unix has these interfaces as a matter of historical accident, what was an excellent design at the time. its hardly the only good point in the space.
you might find that it helps to think about these thing..even when developing important, real-world applications. why shouldn't the kernel be able to call into userspace safely and transfer ownership of a buffer? is that really so terrible to consider?
if this were all in one domain, the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
because of the user kernel boundary we have a copy which is difficult to get around (put the next 1k bytes exactly here, although i really dont care), and some unfriendly and inefficient hacks to weasel around the 'natural' blocking semantics.
even if its completely academic, i think its interesting to look at the user kernel boundary and try to refactor things which have negative structural impacts.
yes. but it really helps if its the right abstraction
my guess is that zipcar probably pays alot to provide the network that their cars currently use.
15 years ago when i looked at the literature there were substantial problems with the efficiency of the selected routes, route convergence and message overhead. these things got much worse as the rate of change in the peer graph goes up.
have things gotten that much better?
what would you call it if they had actually written a linux kernel?
ullman - datalog - 1989 plus or minus a couple years. strictly more powerful and quite a bit easier to program in. and substantially easier to process.
i've done a couple derived languages and they took months/weeks rather than the years the single sql-derived engine i worked on took.
i hardly want to defend sql, its a terribly conceived language.
however, if by 'distributability' you mean execution across machines connected by unreliable networks, then its just as straightforward to implement relations having a single key and a single value as multiple keys and multiple values. all the additional complexity is in the language front end, and its not that bad.
with both query semantics the primary limit in scaling, or concurrency, is the cost of providing isolation, if required, and the workload dependent serialization conflicts.
why is open source crawling through the transom?
still cant get a key eh?
you're right. we should have some kind of place we can come together, present evidence, interpret the law, argue for both sides, and come up with a decision. presided over by someone deemed impartial , with alot of experience in the law.
its really not a very well written book, being largely useless filler.
by christian queinnec is an absolutely great* discourse in the construction of linguistic towers.
or maybe there is a slimeball recruiter in the loop