A modern program is typically made up of many files. Executables, dynamic libraries, data files etc. When you load the program or go into a part of the program you haven't entered yet data is picked out from those files, often in a somewhat random order (especially if the OS memory maps executables and libraries rather than outright loading them).
HDDs are fine at reading a single file sequentially. They suck at picking up lots of little bits from different files.
1: regulators and courts turn a blind eye to the vulnerabilities of the phone system in general and fax in particular. Anyone can copy/paste a signature into a fax and it would be very hard to tell due to the general low quality of fax transmissions. Tapping a phone line a phone line to record passing faxes shouldn't be too difficult either. Similar vulnerabilities in internet based communication systems are considered unacceptable. 2: as a result of 1 internet based replacements for fax are far harder to setup and/or understand than fax. Digital signatures must be used to prove who created something, encyrption must be used to protect agains snooping. All this adds complexity that normal users find hard to deal with. 3: the fact that internet email is free, international and largely anonymous has lead to it becoming overwhelmed with spam. The countermeasures put up against spam have rendered it an unreliable means of communication.
Indeed, there seems to be this irrational idea in many regulatory environments that sending stuff unencrypted over the phone system is fine yet sending it unencrypted over the internet is not.
Seems kinda paradoxical yet practically it makes a lot of sense.
With a traditional VCS you have all clients acting directly on one repo with a linear history. clones/backups may be taken but in order to present a total mess everyone must agree on which repo is the master. If the master goes down everyone must agree on a new master or a horrible mess will ensue.
With a DVCS every checkout is a repo and changesets are pushed or pulled between the repos and history is designed to be nonlinear. However there is still very useful to have one or more repos in shared (or public) locations to allow changes to be easily shared between developers (and if desired the users). Sites like github provide a place for this to save users the hassle of running their own servers.
for it to mean anything, you should check who signed the site's certificate.
Afaict even that is of limited utility because thanks to the webs page by page model there is no enforcement that the cert used to send you the login page is the same cert that will be used when you submit the login form.
Abstractions are leaky, in particular for most higher level protocols to work IP over avian carriers you would almost certainly need to crank up the timeouts.
STOP! You're bankrupting the USPS. They *lose* money on these items.
Do you have a source for that claim and in particular does that source distinguish between overall profit/loss (apportioning some part of the fixed costs to each delivery) and marginal profit/loss?
They'll have to charge the true cost of delivery if they want to actually solve the problem.
As I understand it the real problem with a "postal service"* is that their costs are more related to the size of the service area and the frequency of service than the volume of post. Sending a postman down a street costs about the same regardless of how much mail he puts in each box.
So as mail volumes naturally go down due to competition from electronic communication the average cost of a delivery rises. The governments that own and/or regulate them must choose betwen subsidising them, raising prices or reducing service. None of theese are lightly to be popular and the latter two options run the risk of driving down mail volumes further. Unions add to the problem of course as they are resistant to downsizing.
I suspect in the long run we will end up with an infrequent and possiblly subsidised delivery to everyone, commerical postal services in areas with high mail volume and expensive courior services for the few items that absoloutely must be delivered physically and quickly to an address in the middle of nowhere.
Using a searchlight is far more likely to tell the enemy your position than to tell you the enemy's position because any searchlight will leak some light off-axis and it takes far less light to spot a light source than to use a light source to spot a target.
And that is the root of the problem. In a first past the post democracy "you only have two realistic choices, choose the one you hate least" becomes a self-fulfilling prophecy. Especially when both sides are well known for breaking their promises.
Sadly, the only way around this (short of having very strict and rigorously-enforced anti-trust laws - which take a long time to work; the initial complaint against MS above was made in 1994 - an appeal is still pending) is compulsory licensing. This would mean we could get dozens of Netflixes and Hulus, iTuneses and Spotifies, Steams and Origins, all offering competing services to access the same content - giving consumers the choice for which service to go with (rather than the copyright owner), depending on the terms ($n/mo for streaming v $m per download etc.) - with copyright owners getting paid a 'fair' amount, and not having to worry about endless contract negotiations.
It would also require someone to decide what is "fair". Is an hour of "big brother" or "american idol" worth the same as an hour of "planet earth" or "mythbusters"?
Anycast works great for protocols like 6to4, DNS or NTP where each packet is a complete transaction and it really doesn't matter if all your packets end up at the same server. It isn't so good for TCP where the client and server have shared state. In the worst case where a route is flapping you may never maintain a connection for more than a few seconds as your packets get repeatedly sent to different server.
For music, Apple is the company that finally ended DRM.
Apple pushed the music industry into a corner which they could only get out of by abandoning DRM. Whether this was intentional or just a side affect of how things played out with the ipod we will never really know.
Mysql put their client libraries under the GPL. By common intepretations of the GPL if you link against a GPL library you have to release your program under the GPL. So if you want to develop propietry apps linked againstthe mysql client you had to buy a commerical license for mysql. IIRC at one stage they were even trying to claim that the GPL applied to the wire protocol (so even if you rewrote the client libs you weren't in the clear according to them) dunno if they still are. So yes you can fork it but not all users can use your fork.
Though personally I don't think mysql was a reason to stop the merger. There are plenty of other opensource databases under freer licenses than mysql and it's not like mysql and oracle were ever really in much competition being at opposite ends of the market.
The only time that would cause a problem is if the rules for DST change between when you set the alarm and when it goes off
Something that can easilly happen given the way some governments change DST rules at short notice and the only mechanism for pushing out DST rule changes is for the vendor to roll them into a software update (and to make things more fun windows system for representing DST rules is oversimplifies) or an admin to change them manually. Even worse you can get into a situation where different nodes on your network (or even different peices of software on the same computer) have different ideas of the DST rules and where (if clocks can be set manually by end users or well meaning but ignorant admins) some nodes may have correct local time but wrong universal time.
Oh and there is the fun that afaict there is no official standard for how to represent an area with consistent time rules. Both MS and *nix seem to use city names but I don't think their use of them is consistent with each other.
they could also be stored with the original time value (i.e. what specific timezone was indicated on entry, whether it was implicit or explicit).
That is indeed what needs to be done. Then whenever a rule change update comes in you need to
1: recompute the UTC equivilents for all affected timestamps 2: recheck for conflicts 3: generate warnings for users (both generally and pulling out any changes particually likely to surprise a given user) 4: decide how to deal with stuff that was previously scheduled at an unambiguous time but is now scheduled at times that are either impossible or ambiguous
It's all doable but doing it correctly (especially when you have to work against operating systems that do it incorrectly) is a lot of work and easilly written off until the change strikes. Just as many people in the UK assumed VAT would always be 17.5% and many people assumed (and now that Y2K has passed have gone back to assuming) that their systems would be dead long before their use of two digit years would become a problem.
So you can drive very slowly to the next light and not wait or you can drive there quickly and then wait. Either way your average speed is going to suck.
If that is happening on the main road through an area then someone really needs to fix the timing of the lights so cars on the main road can proceed along it at a reasonable speed without having to stop (granted this can become difficult in areas where there is no one "main road")
The biggest problem I see for an auto-drive system in normal driving (accident handling has it's own set of problems) is going from the combination of a rough map, a rough position indication (according to wikipedia ordinary GPS currently has an accuracy of arround 20m) and visual clues to successful junction navigation (particually at junctions with lots of exits packed close together).
Maybe i'm a pessimist but this isn't a problem I see being solved without adding infrastructure on the ground to provide accurate and up to date junction information in a machine friendly format.
Another thing to consider is that assuming people yield to traffic on the roundabout* then entrances immediately after popular exists will end up prioritised over other entrances. Depending on the importance of the various feeder roads that behaviour may or many not be desirable. With traffic lights the planners can control the priority of different entrances to try and avoid gridlock.
Also afaict if congestion backs up onto a roundabout it will completely freeze the roundabout whereas other junction types may still be able to permit traffic flow in other directions (particually if the roads feeding the junction have different lanes for different directions.
*If people DON'T yeild to traffic on the roundabout then the likely result is gridlock.
DST really isn't that difficult either. Internally, everything should simply run on UTC, display time is a simple offset from that. Whether that offset is fixed for a specific geographic location or changes by an hour is mostly irrelevant to the issue. The ONLY problem it causes is the one hour that's impossible and the one hour that's ambiguous for any particular time zone at the switch time.
Doing everything internally in UTC may seem like a good idea but it causes a couple of problems.
1: a user sets a daily alarm from 7am local time. 2: a user sets an alarm for a meeting at 1pm local time a few months in the future. Then the DST rules change moving that month into the DST period.
In both cases the reasonable expectation of the user (given that they set the alarm using local time) is that the alarm will continue to be set at the same local time but if the system uses UTC for everything (and doesn't apply hacky corrections) then the alarm will continue to be set at the same time local time which maps to a different time in universal time.
Showing a user local time while working internally in UTC is a recipie for behaviours that while perfectly logical to computer geeks break basic expectations of normal users.
TCP/IP was not designed to fit the OSI model therefore any attempt at mapping TCP/IP onto the OSI model will be imperfect
TCP sits above IP and is conventionally considered to be at OSI level four (though according to wikipedia it implements some functionality that is in OSI level 5). UDP also sits above IP and therefore is also conventionally considered to be at OSI level four (though it implements hardly any of the functionality OSI associates with that layer).
The rest of the functionality that OSI places in layer 5 and the functionality that OSI places in layer 6 is not provided by the TCP/IP stack. If applications require that functionality then they need to implement it themselves or use libraries to provide it.
The big problem is you get it to alaska and then what? Afaict there are no railways linking alaska to the rest of north america and the roads don't go anywhere near the Bering Strait. Are the russians prepared to pay for a railway through alaska and a fair way into canada to join up to the rest of the north american rail network?
Slashdot Mirror
Files that get read from disk - ONCE.
A modern program is typically made up of many files. Executables, dynamic libraries, data files etc. When you load the program or go into a part of the program you haven't entered yet data is picked out from those files, often in a somewhat random order (especially if the OS memory maps executables and libraries rather than outright loading them).
HDDs are fine at reading a single file sequentially. They suck at picking up lots of little bits from different files.
Afaict fax refuses to die for a few reasons
1: regulators and courts turn a blind eye to the vulnerabilities of the phone system in general and fax in particular. Anyone can copy/paste a signature into a fax and it would be very hard to tell due to the general low quality of fax transmissions. Tapping a phone line a phone line to record passing faxes shouldn't be too difficult either. Similar vulnerabilities in internet based communication systems are considered unacceptable.
2: as a result of 1 internet based replacements for fax are far harder to setup and/or understand than fax. Digital signatures must be used to prove who created something, encyrption must be used to protect agains snooping. All this adds complexity that normal users find hard to deal with.
3: the fact that internet email is free, international and largely anonymous has lead to it becoming overwhelmed with spam. The countermeasures put up against spam have rendered it an unreliable means of communication.
Emailing HIPPA documents in not an option
Indeed, there seems to be this irrational idea in many regulatory environments that sending stuff unencrypted over the phone system is fine yet sending it unencrypted over the internet is not.
Seems kinda paradoxical yet practically it makes a lot of sense.
With a traditional VCS you have all clients acting directly on one repo with a linear history. clones/backups may be taken but in order to present a total mess everyone must agree on which repo is the master. If the master goes down everyone must agree on a new master or a horrible mess will ensue.
With a DVCS every checkout is a repo and changesets are pushed or pulled between the repos and history is designed to be nonlinear. However there is still very useful to have one or more repos in shared (or public) locations to allow changes to be easily shared between developers (and if desired the users). Sites like github provide a place for this to save users the hassle of running their own servers.
for it to mean anything, you should check who signed the site's certificate.
Afaict even that is of limited utility because thanks to the webs page by page model there is no enforcement that the cert used to send you the login page is the same cert that will be used when you submit the login form.
Abstractions are leaky, in particular for most higher level protocols to work IP over avian carriers you would almost certainly need to crank up the timeouts.
STOP! You're bankrupting the USPS. They *lose* money on these items.
Do you have a source for that claim and in particular does that source distinguish between overall profit/loss (apportioning some part of the fixed costs to each delivery) and marginal profit/loss?
They'll have to charge the true cost of delivery if they want to actually solve the problem.
As I understand it the real problem with a "postal service"* is that their costs are more related to the size of the service area and the frequency of service than the volume of post. Sending a postman down a street costs about the same regardless of how much mail he puts in each box.
So as mail volumes naturally go down due to competition from electronic communication the average cost of a delivery rises. The governments that own and/or regulate them must choose betwen subsidising them, raising prices or reducing service. None of theese are lightly to be popular and the latter two options run the risk of driving down mail volumes further. Unions add to the problem of course as they are resistant to downsizing.
I suspect in the long run we will end up with an infrequent and possiblly subsidised delivery to everyone, commerical postal services in areas with high mail volume and expensive courior services for the few items that absoloutely must be delivered physically and quickly to an address in the middle of nowhere.
Using a searchlight is far more likely to tell the enemy your position than to tell you the enemy's position because any searchlight will leak some light off-axis and it takes far less light to spot a light source than to use a light source to spot a target.
And therefor a single point of failure.
Better a single point of failure than many points that can all cause complete failure of the system's security.
The current CA model where any CA can issue a cert for any domain is like storing your data on a raid 0 array.
AS long as the net is moving at the same velocity as the debris it's trying to capture.
Fixed that for you ;)
And that is the root of the problem. In a first past the post democracy "you only have two realistic choices, choose the one you hate least" becomes a self-fulfilling prophecy. Especially when both sides are well known for breaking their promises.
Sadly, the only way around this (short of having very strict and rigorously-enforced anti-trust laws - which take a long time to work; the initial complaint against MS above was made in 1994 - an appeal is still pending) is compulsory licensing. This would mean we could get dozens of Netflixes and Hulus, iTuneses and Spotifies, Steams and Origins, all offering competing services to access the same content - giving consumers the choice for which service to go with (rather than the copyright owner), depending on the terms ($n/mo for streaming v $m per download etc.) - with copyright owners getting paid a 'fair' amount, and not having to worry about endless contract negotiations.
It would also require someone to decide what is "fair". Is an hour of "big brother" or "american idol" worth the same as an hour of "planet earth" or "mythbusters"?
Anycast works great for protocols like 6to4, DNS or NTP where each packet is a complete transaction and it really doesn't matter if all your packets end up at the same server. It isn't so good for TCP where the client and server have shared state. In the worst case where a route is flapping you may never maintain a connection for more than a few seconds as your packets get repeatedly sent to different server.
For music, Apple is the company that finally ended DRM.
Apple pushed the music industry into a corner which they could only get out of by abandoning DRM. Whether this was intentional or just a side affect of how things played out with the ipod we will never really know.
Given that it is free and forkable
Mysql put their client libraries under the GPL. By common intepretations of the GPL if you link against a GPL library you have to release your program under the GPL. So if you want to develop propietry apps linked againstthe mysql client you had to buy a commerical license for mysql. IIRC at one stage they were even trying to claim that the GPL applied to the wire protocol (so even if you rewrote the client libs you weren't in the clear according to them) dunno if they still are. So yes you can fork it but not all users can use your fork.
Though personally I don't think mysql was a reason to stop the merger. There are plenty of other opensource databases under freer licenses than mysql and it's not like mysql and oracle were ever really in much competition being at opposite ends of the market.
The only time that would cause a problem is if the rules for DST change between when you set the alarm and when it goes off
Something that can easilly happen given the way some governments change DST rules at short notice and the only mechanism for pushing out DST rule changes is for the vendor to roll them into a software update (and to make things more fun windows system for representing DST rules is oversimplifies) or an admin to change them manually. Even worse you can get into a situation where different nodes on your network (or even different peices of software on the same computer) have different ideas of the DST rules and where (if clocks can be set manually by end users or well meaning but ignorant admins) some nodes may have correct local time but wrong universal time.
Oh and there is the fun that afaict there is no official standard for how to represent an area with consistent time rules. Both MS and *nix seem to use city names but I don't think their use of them is consistent with each other.
they could also be stored with the original time value (i.e. what specific timezone was indicated on entry, whether it was implicit or explicit).
That is indeed what needs to be done. Then whenever a rule change update comes in you need to
1: recompute the UTC equivilents for all affected timestamps
2: recheck for conflicts
3: generate warnings for users (both generally and pulling out any changes particually likely to surprise a given user)
4: decide how to deal with stuff that was previously scheduled at an unambiguous time but is now scheduled at times that are either impossible or ambiguous
It's all doable but doing it correctly (especially when you have to work against operating systems that do it incorrectly) is a lot of work and easilly written off until the change strikes. Just as many people in the UK assumed VAT would always be 17.5% and many people assumed (and now that Y2K has passed have gone back to assuming) that their systems would be dead long before their use of two digit years would become a problem.
The test equipment spinoff, eh, who even remembers their name.
Anyone who actually uses high end test equipment?
So you can drive very slowly to the next light and not wait or you can drive there quickly and then wait. Either way your average speed is going to suck.
If that is happening on the main road through an area then someone really needs to fix the timing of the lights so cars on the main road can proceed along it at a reasonable speed without having to stop (granted this can become difficult in areas where there is no one "main road")
The biggest problem I see for an auto-drive system in normal driving (accident handling has it's own set of problems) is going from the combination of a rough map, a rough position indication (according to wikipedia ordinary GPS currently has an accuracy of arround 20m) and visual clues to successful junction navigation (particually at junctions with lots of exits packed close together).
Maybe i'm a pessimist but this isn't a problem I see being solved without adding infrastructure on the ground to provide accurate and up to date junction information in a machine friendly format.
Another thing to consider is that assuming people yield to traffic on the roundabout* then entrances immediately after popular exists will end up prioritised over other entrances. Depending on the importance of the various feeder roads that behaviour may or many not be desirable. With traffic lights the planners can control the priority of different entrances to try and avoid gridlock.
Also afaict if congestion backs up onto a roundabout it will completely freeze the roundabout whereas other junction types may still be able to permit traffic flow in other directions (particually if the roads feeding the junction have different lanes for different directions.
*If people DON'T yeild to traffic on the roundabout then the likely result is gridlock.
then the alarm will continue to be set at the same time local time which maps to a different time in universal time.
That should have said the alarm will continue to be set at the same time in universal time which maps to a different time in local time.
DST really isn't that difficult either. Internally, everything should simply run on UTC, display time is a simple offset from that. Whether that offset is fixed for a specific geographic location or changes by an hour is mostly irrelevant to the issue. The ONLY problem it causes is the one hour that's impossible and the one hour that's ambiguous for any particular time zone at the switch time.
Doing everything internally in UTC may seem like a good idea but it causes a couple of problems.
1: a user sets a daily alarm from 7am local time.
2: a user sets an alarm for a meeting at 1pm local time a few months in the future. Then the DST rules change moving that month into the DST period.
In both cases the reasonable expectation of the user (given that they set the alarm using local time) is that the alarm will continue to be set at the same local time but if the system uses UTC for everything (and doesn't apply hacky corrections) then the alarm will continue to be set at the same time local time which maps to a different time in universal time.
Showing a user local time while working internally in UTC is a recipie for behaviours that while perfectly logical to computer geeks break basic expectations of normal users.
TCP/IP was not designed to fit the OSI model therefore any attempt at mapping TCP/IP onto the OSI model will be imperfect
TCP sits above IP and is conventionally considered to be at OSI level four (though according to wikipedia it implements some functionality that is in OSI level 5). UDP also sits above IP and therefore is also conventionally considered to be at OSI level four (though it implements hardly any of the functionality OSI associates with that layer).
The rest of the functionality that OSI places in layer 5 and the functionality that OSI places in layer 6 is not provided by the TCP/IP stack. If applications require that functionality then they need to implement it themselves or use libraries to provide it.
Haven't pretty much all the phone vendors other than apple gone with micro USB already due to pressure from the EU and china?
The big problem is you get it to alaska and then what? Afaict there are no railways linking alaska to the rest of north america and the roads don't go anywhere near the Bering Strait. Are the russians prepared to pay for a railway through alaska and a fair way into canada to join up to the rest of the north american rail network?