A kernel has to do tricky things like change page mapping tables, ensure that actions that need to be atomic really are atomic even in multi-processor systems, save processor state on context switches, detect when a clean page of ram is modified making it dirty and so-on. These things are sufficiently specialised that high level languages don't provide tools for them (if they did it would just be moving complexity from kernel devs to compiler devs) so the kernel developers have to write them themselves in assembly. Different processors will have different instruction sets and hence will provide different building blocks to build up these features from.
From other comments on this article I understand the issue is that the 386 lacks certain features of it's modern descendents that are very useful in a modern kernel and while there are ways of acheiving the same thing on a 385 they are far more cumbersome to implement and the implementations are poorly tested (because almost noone runs current linux on a 386).
Not true the CPU supports use of those registers in 64-bit mode.
At one stage MS was telling programmers not to use the x87 in 64-bit mode but at least according to http://www.virtualdub.org/blog/pivot/entry.php?id=107 they have now declard it's ok for 64-bit user-mode apps to use the x87.
I just can't fathom why anyone would sign up for a service where they would have to pay for calls received, beyond the base rate.
Because the alternative is not having mobile communications at all and people value mobile communications sufficiently highly to put up with the terms they have to agree to in order to get it.
For many classes of device the choice comes down to either propietary firmware in a rom on the card or propietary firmware included with the operating system. Do you really belive the former is better for freedom? if so why?
As to what C++ achives it's the automation of tedious and error-prone boilerplate. Rather than manually incrementing and decrementing reference counts you can have it happen automatically as values are copied and overwritten. Rather than manually building procedure address tables for polymorphism you can get the compiler to do it for you.
TCP tries to (and usually succeeds in) trasfer a stream of bytes reliablly and in the right order over an unreliable packet based system.
To achieve this two things have to happen 1: the sender must resend lost packets 2: the recipiant must hold packets after
However there is no way for a sender to determine if a packet has actually been lost or just delayed. So the sender must use a timeout to deem a packet as lost and retransmit it.
Now suppose someone builds a tunnel using TCP and runs TCP over that tunnel so your stack looks something like.
Application TCP (inner) IP Tunneling protocol TCP (outer) IP underlying network
Everything works fine as long as no packets are lost. However when a packet is lost by the underlying network the outer TCP layer freezes all transmissions through the tunnel until it has retransmitted the packet. During this time it is likely that the innner TCP layer will also deem the packet(s) lost and try to retransmit them (possiblly more than once due to the auto-adjusting timeouts used by TCP). Then when the outer TCP does recover it will deliver both the original packet and the retransmission from the outer TCP. This behaviour is very similar to what happens when a network is congested and make cause the inner TCP to unnessacerally back off the data rate.
Still there were options other than "have their own hardware engineers designing server hardware" and "screw over anyone trying to run their server software in a datacenter environment". Rebadging hardware from a major server vendor being one, selling (expensive) licenses to run it in virtualisation on non-apple hardware being another.
Man! That always burns me up to. I mean, once I spec out a system from somewhere else that actually meets the same specification why do the prices always line up? I can't figure that one out either.
Good question.
The answer is that apple avoids making "normal" computers. So trying to find a machine that is perfectly equivilent to a mac requires (if it's possible at all, afaict noone makes a direct equivalent to the retina macbooks) means you end up in expensive speciality product lines.
OTOH that is not how people normally buy a computer. They start with a list of requirements and then look for machines that meet it. And if you do things that way round apple machines generally come out much more expensive.
Directx is a bloated piece of proprietary shit that developers cannot look through to debug their code, most of it is guess work and trial and error to figure out what the most optimal means of doing something with it is. Opensource graphics libraries and opensource graphics drivers will make better faster games. Less black boxes means better understanding means better code means better code.
Realistically though anyone seriously gaming on linux is likely to be using either NVIDIA or ATIs propietary drivers. IIRC both of those replace the mesa implementation of opengl with their own.
if you think you have to upgrade to do IPv6, you're either foolhardy or not buying the right equipment in the first place.
Or you have just had the equipment for a while. Proper routers that can route IP packets in hardware are expensive so companies generally only replace them when they have to.
AIUI there are plenty of older routers out there that do v4 in hardware but do v6 in software. So you can bring up IPv6 on them and everything is fine until people start really using it then you have problems and the only solutions are to either turn off IPv6 or do a forklift upgrade. For some ISPs the forklift upgrades were needed anyway to cope with increased demand but for others that won't have been the case.
including hiring people.
Running dual stack means that all IP related configuration (interface addressing, routing rules, firewall rules, DNS entries etc) needs to be duplicated. That is a fair bit of extra work that someone has to do. It can also make troubleshooting a lot harder.
The fact is important servers will remain available on IPv4 for the forseeable future (even if it means taking away public IPs from end users), end users will be provided with some method of accessing IPv4 only resources and for most companies/organisations* there are more than enough private IPv4 addresess to address internal systems.
I support IPv6 where possible in services I run because I believe that doing so is a sign of support for an open internet but there isn't really much justification for doing so beyond that.
* Yes I am aware that there are a handful of companies for which this is not the case.
The datacenter operators can provide multiple sites but ultimately it's up to the customers to pay for servers at multiple sites and design their applications to fail over cleanly.
Afaict fiber cables don't care about being underwater and any sane datacenter will run their network gear off protected power. So as long as the power stays on and the datacenters at the other end of the fibers stay up communication should be maintained.
Any government that is seriously looking at a ground invasion of their primary territory is going to turn as much of their population as they can into a means of resisting that invasion whether directly by conscripting people to become soldiers or indirectly by forcing factories to switch to producing munitions. They are also going to put out propaganda demonising the enemy.
The strong line dividing civilians and soldiers we draw in the west today is a result of decades of having no real threat of ground invasion and of having techology that allows for a military force that is small in numbers but high on strength.
35mm itself (packaged differently) is basically a 19th century movie film standard
Note that as well as using different reels stills cameras run the film sideways rather than vertically meaning a frame on a 35mm stills camera is quite a bit bigger than a frame on a 35mm movie camera.
His "(typical examples of passive ps/2 to USB adapters that are not true ps/2 to USB signal converters)" shows one adaptor that is probablly passive and two that are clearly active (you can't connect both a keyboard and a mouse to the same USB port without an active adaptor).
Note however that being active doesn't gaurantee it will work with your device. From what I can gather some cheap adaptors play fast and loose with the PS/2 specs (in particular I believe some of them try to run the ports at 3.3V rather than 5V).
Just to clear something up ethernet autonegotiation does not even attempt to measure cable quality. So a "consistently bad" run is just as much of a problem for ethernet as a "flaky" run.
When people say "printing" in this context they really mean creating.
The Bureau of Engraving and Printing and the Mint produce the physical manifestations of money but they don't legally become money until they are issued.
The fedral reserve creates money, that money may be either in the form of numbers in a database or in the form of notes that are printed by the Bureau of engraving and printing. The treasury also creates money (but in much smaller quantities) by issuing coins produced by the mint.
Owning bitcoin mining hardware is a risky buisness. The income generated by mining hardware is dependent on both the value of each bitcoin and the total ammount of mining power out there both of which are difficult to predict.
Selling the tools rather than running them yourself spreads that risk around more people.
I'm not the GP but there are a few measures that can be considered such as
1: deliberately slow hash functions. You can make the crackers job a few orders of magnitude harder this way. 2: dedicated password checking servers (ideally a seperate machine but privilage seperation on the same box is better than nothing) so that cracking your webapp doesn't hand the attackers the password hashes on a silver platter. 3: physical hardware the user is given that provides one-time use security codes
Of course none of these measures are free and that means most forums etc won't bother with them:/
These problems CAN be mostly solved in software. A bootloader that lives with the device and never needs to be updated because it doesn't interact with the outside world can pass the necessary information to the kernel. The first time you upgraded from a legacy image to a universal image you'd have to update your bootloader to provide the necessary information but that only has to be done once per device.
It's "just" a matter of getting the work done. Some linux developers are working on it but really if it's going to be successful in the long term we need to get the SoC vendors cooperating with the linux kernel devs to minimise unnecessary changes, to reuse code where possible rather than writing a new driver from scratch and to provide drivers of sufficient quality to be merged into mainline.
Full term baby: definitely life. It breathes without assistance, it maintains it's own body temperature (not perfectly, true), its skin is suited to exposure to air...IOW, it is fully adapted to function as a biological unit in its nominal environment.
OTOH it's only way to get the nourishment it needs to survive is to cry until either the mother or some other adult provides it.
My original order was placed in July 5th, 2012 and I just got it on December 1, 2012 in the mail. I live in Georgia, US so I knew it would take a while to get "across the pond" but was a let down seeing it was made in china when they promised revision 2 boards were made in UK and they clearly are not.
I think you are misremembering.
Quote from the "made in the UK" post
"The upshot of all this? Element14/Premier Farnell have made the decision to move the bulk of their Raspberry Pi manufacture to South Wales."
Note that it is only one of the two manufacturing partners and for that partner it is only "the bulk of their raspberry pi manufacture" not all of it.
Really to test properly a multimeter alone is not enough, you need a known test load.
In other words hack together a board with a micro USB socket and a 5 ohm 7-10W resistor (technically 5W would be enough but I like to leave some margin). Then plug your PSU into it and measure the voltage. If you have a scope you can also measure to see if there is any significant ripple.
Slashdot Mirror
A kernel has to do tricky things like change page mapping tables, ensure that actions that need to be atomic really are atomic even in multi-processor systems, save processor state on context switches, detect when a clean page of ram is modified making it dirty and so-on. These things are sufficiently specialised that high level languages don't provide tools for them (if they did it would just be moving complexity from kernel devs to compiler devs) so the kernel developers have to write them themselves in assembly. Different processors will have different instruction sets and hence will provide different building blocks to build up these features from.
From other comments on this article I understand the issue is that the 386 lacks certain features of it's modern descendents that are very useful in a modern kernel and while there are ways of acheiving the same thing on a 385 they are far more cumbersome to implement and the implementations are poorly tested (because almost noone runs current linux on a 386).
Not true the CPU supports use of those registers in 64-bit mode.
At one stage MS was telling programmers not to use the x87 in 64-bit mode but at least according to http://www.virtualdub.org/blog/pivot/entry.php?id=107 they have now declard it's ok for 64-bit user-mode apps to use the x87.
I just can't fathom why anyone would sign up for a service where they would have to pay for calls received, beyond the base rate.
Because the alternative is not having mobile communications at all and people value mobile communications sufficiently highly to put up with the terms they have to agree to in order to get it.
For many classes of device the choice comes down to either propietary firmware in a rom on the card or propietary firmware included with the operating system. Do you really belive the former is better for freedom? if so why?
IIRC modern windows is a mixture of C and C++.
As to what C++ achives it's the automation of tedious and error-prone boilerplate. Rather than manually incrementing and decrementing reference counts you can have it happen automatically as values are copied and overwritten. Rather than manually building procedure address tables for polymorphism you can get the compiler to do it for you.
it will deliver both the original packet and the retransmission from the outer TCP
That should have said
it will deliver both the original packet and the retransmission from the inner TCP
TCP tries to (and usually succeeds in) trasfer a stream of bytes reliablly and in the right order over an unreliable packet based system.
To achieve this two things have to happen
1: the sender must resend lost packets
2: the recipiant must hold packets after
However there is no way for a sender to determine if a packet has actually been lost or just delayed. So the sender must use a timeout to deem a packet as lost and retransmit it.
Now suppose someone builds a tunnel using TCP and runs TCP over that tunnel so your stack looks something like.
Application
TCP (inner)
IP
Tunneling protocol
TCP (outer)
IP
underlying network
Everything works fine as long as no packets are lost. However when a packet is lost by the underlying network the outer TCP layer freezes all transmissions through the tunnel until it has retransmitted the packet. During this time it is likely that the innner TCP layer will also deem the packet(s) lost and try to retransmit them (possiblly more than once due to the auto-adjusting timeouts used by TCP). Then when the outer TCP does recover it will deliver both the original packet and the retransmission from the outer TCP. This behaviour is very similar to what happens when a network is congested and make cause the inner TCP to unnessacerally back off the data rate.
Still there were options other than "have their own hardware engineers designing server hardware" and "screw over anyone trying to run their server software in a datacenter environment". Rebadging hardware from a major server vendor being one, selling (expensive) licenses to run it in virtualisation on non-apple hardware being another.
Man! That always burns me up to. I mean, once I spec out a system from somewhere else that actually meets the same specification why do the prices always line up? I can't figure that one out either.
Good question.
The answer is that apple avoids making "normal" computers. So trying to find a machine that is perfectly equivilent to a mac requires (if it's possible at all, afaict noone makes a direct equivalent to the retina macbooks) means you end up in expensive speciality product lines.
OTOH that is not how people normally buy a computer. They start with a list of requirements and then look for machines that meet it. And if you do things that way round apple machines generally come out much more expensive.
Directx is a bloated piece of proprietary shit that developers cannot look through to debug their code, most of it is guess work and trial and error to figure out what the most optimal means of doing something with it is. Opensource graphics libraries and opensource graphics drivers will make better faster games. Less black boxes means better understanding means better code means better code.
Realistically though anyone seriously gaming on linux is likely to be using either NVIDIA or ATIs propietary drivers. IIRC both of those replace the mesa implementation of opengl with their own.
if you think you have to upgrade to do IPv6, you're either foolhardy or not buying the right equipment in the first place.
Or you have just had the equipment for a while. Proper routers that can route IP packets in hardware are expensive so companies generally only replace them when they have to.
AIUI there are plenty of older routers out there that do v4 in hardware but do v6 in software. So you can bring up IPv6 on them and everything is fine until people start really using it then you have problems and the only solutions are to either turn off IPv6 or do a forklift upgrade. For some ISPs the forklift upgrades were needed anyway to cope with increased demand but for others that won't have been the case.
including hiring people.
Running dual stack means that all IP related configuration (interface addressing, routing rules, firewall rules, DNS entries etc) needs to be duplicated. That is a fair bit of extra work that someone has to do. It can also make troubleshooting a lot harder.
The fact is important servers will remain available on IPv4 for the forseeable future (even if it means taking away public IPs from end users), end users will be provided with some method of accessing IPv4 only resources and for most companies/organisations* there are more than enough private IPv4 addresess to address internal systems.
I support IPv6 where possible in services I run because I believe that doing so is a sign of support for an open internet but there isn't really much justification for doing so beyond that.
* Yes I am aware that there are a handful of companies for which this is not the case.
The datacenter operators can provide multiple sites but ultimately it's up to the customers to pay for servers at multiple sites and design their applications to fail over cleanly.
Why?
Afaict fiber cables don't care about being underwater and any sane datacenter will run their network gear off protected power. So as long as the power stays on and the datacenters at the other end of the fibers stay up communication should be maintained.
Any government that is seriously looking at a ground invasion of their primary territory is going to turn as much of their population as they can into a means of resisting that invasion whether directly by conscripting people to become soldiers or indirectly by forcing factories to switch to producing munitions. They are also going to put out propaganda demonising the enemy.
The strong line dividing civilians and soldiers we draw in the west today is a result of decades of having no real threat of ground invasion and of having techology that allows for a military force that is small in numbers but high on strength.
35mm itself (packaged differently) is basically a 19th century movie film standard
Note that as well as using different reels stills cameras run the film sideways rather than vertically meaning a frame on a 35mm stills camera is quite a bit bigger than a frame on a 35mm movie camera.
His "(typical examples of passive ps/2 to USB adapters that are not true ps/2 to USB signal converters)" shows one adaptor that is probablly passive and two that are clearly active (you can't connect both a keyboard and a mouse to the same USB port without an active adaptor).
Note however that being active doesn't gaurantee it will work with your device. From what I can gather some cheap adaptors play fast and loose with the PS/2 specs (in particular I believe some of them try to run the ports at 3.3V rather than 5V).
Just to clear something up ethernet autonegotiation does not even attempt to measure cable quality. So a "consistently bad" run is just as much of a problem for ethernet as a "flaky" run.
When people say "printing" in this context they really mean creating.
The Bureau of Engraving and Printing and the Mint produce the physical manifestations of money but they don't legally become money until they are issued.
The fedral reserve creates money, that money may be either in the form of numbers in a database or in the form of notes that are printed by the Bureau of engraving and printing.
The treasury also creates money (but in much smaller quantities) by issuing coins produced by the mint.
Owning bitcoin mining hardware is a risky buisness. The income generated by mining hardware is dependent on both the value of each bitcoin and the total ammount of mining power out there both of which are difficult to predict.
Selling the tools rather than running them yourself spreads that risk around more people.
I'm not the GP but there are a few measures that can be considered such as
1: deliberately slow hash functions. You can make the crackers job a few orders of magnitude harder this way.
2: dedicated password checking servers (ideally a seperate machine but privilage seperation on the same box is better than nothing) so that cracking your webapp doesn't hand the attackers the password hashes on a silver platter.
3: physical hardware the user is given that provides one-time use security codes
Of course none of these measures are free and that means most forums etc won't bother with them :/
Everything works wonderfully on other architectures.
For sufficiently small values of "wonderfully".
These problems CAN be mostly solved in software. A bootloader that lives with the device and never needs to be updated because it doesn't interact with the outside world can pass the necessary information to the kernel. The first time you upgraded from a legacy image to a universal image you'd have to update your bootloader to provide the necessary information but that only has to be done once per device.
It's "just" a matter of getting the work done. Some linux developers are working on it but really if it's going to be successful in the long term we need to get the SoC vendors cooperating with the linux kernel devs to minimise unnecessary changes, to reuse code where possible rather than writing a new driver from scratch and to provide drivers of sufficient quality to be merged into mainline.
Full term baby: definitely life. It breathes without assistance, it maintains it's own body temperature (not perfectly, true), its skin is suited to exposure to air...IOW, it is fully adapted to function as a biological unit in its nominal environment.
OTOH it's only way to get the nourishment it needs to survive is to cry until either the mother or some other adult provides it.
My original order was placed in July 5th, 2012 and I just got it on December 1, 2012 in the mail. I live in Georgia, US so I knew it would take a while to get "across the pond" but was a let down seeing it was made in china when they promised revision 2 boards were made in UK and they clearly are not.
I think you are misremembering.
Quote from the "made in the UK" post
"The upshot of all this? Element14/Premier Farnell have made the decision to move the bulk of their Raspberry Pi manufacture to South Wales."
Note that it is only one of the two manufacturing partners and for that partner it is only "the bulk of their raspberry pi manufacture" not all of it.
Really to test properly a multimeter alone is not enough, you need a known test load.
In other words hack together a board with a micro USB socket and a 5 ohm 7-10W resistor (technically 5W would be enough but I like to leave some margin). Then plug your PSU into it and measure the voltage. If you have a scope you can also measure to see if there is any significant ripple.