After Microsoft stopped to sell it four years ago?
Depends what you mean by "stopped to sell it"
Sure you can't buy a retail box that says "windows XP" on it or a computer whos license sticker says "windows XP" unless you find it old stock but you can still get OEM copies and volume licenses that include downgrade rights (though IIRC the OEMs are no longer allowed to sell it pre-downgraded, you have to downgrade yourself) and i'm pretty sure you can still buy XP for inclusion in embedded setups too.
I find that most of the time you can grab a source package from testing/unstable and build it on stable with only minor modifications (sometimes none at all) and get a usable package.
But ultimately yes someone has to do the work of preparing the software you want in a form that is suitable for what you are going to run it on before you can deploy it.
Personally given how cheap hard drives are nowadays (even after the flood) I'd question the point of compressing at rip time at all.
Ripping requires regular human attention so if your compression processes can't keep up with the ripping then i'd suggest just not compressing at rip time. If you want an encoded version for use on portable players you can do that as a batch job when you are not sitting in front of the machine.
So, like you said, it's all about duration and area.
And surrounding environment.
Trigger that spark plug in normal air and not much will happen. Trigger it in an engine cylinder and the fuel-air mixture will ignite pushing the piston down with the cylinder wall containing the blast. Trigger it in an room filled with the correct fuel-air mixture and boom
According to wikipedia they lost their monoploy on instant photography in the USA in the mid 1990s as their patents expired and with them their ability to restrict where instax was sold.
dunno how much impact that had in the grand scheme of things though.
Afaict people generally withdraw relatively large denominations from the bank and then spend them in shops taking change in smaller denominations which they either spend back in the shops or put in a jar and take back to the bank.
So for dollar coins to become widespread they need to find their way into shop tills in significant numbers. For that to happen one of two things need to happen
1: shopkeepers decide to order dollar coins instead of dollar bills from the bank 2: the banks stop distributing dollar bills.
The plan was for the B to be released first as the intial release was aimed at early adoptors and developers, the model A would then follow soon afterwards.
However that was back when they throught demand for the Pi would be in the tens of thousands. With the manufacturing partners scrambling to meet demand (and being frustrated by SoC lead times) they did not want to divert SoCs away from model B production to model A production.
Now that the situation is starting to improve and stabalise they are finally bringing up the model A production (though how long it will be before they are readilly available is anyones guess).
Or rather it didn't route through it in the first place.
In europe and north america we have networks of overland fibers because we have sufficient political stability that people aren't worried that their links run through intervening countries. If germany or france (or even the netherlands) shut down all internet links it would cause a LOT of pain for internet users in europe and to a lesser extent across the world but noone is seriously worried about that happening.
OTOH in less stable parts of the world what you see is undersea cables hugging the coast with a landing point in every country they run past. If one country shuts down it's landing points noone else really cares.
But if the exam gives me the choice between using a basic "scientific" calculator and using a "graphic" calculator i'm going to pick the latter. Having enough display space to enter a long sum and then check it was entered correctly is a killer feature IMO (though modern scientific calculators are much better than the old ones in this regard). The graphing functions are mostly useful as a quick sanity check or to get a rough feel for the shape of a function you were about to do some analysis on.
Never used the programming features myself. Writing a program before the exam and taking it in was considered cheating (the calculators were supposed to have their memory reset before the exam to prevent this though in practice it never actually happened) and I don't think there would have been time to write one during the actual exam.
Normally the proper solution is to actually include in a build some way of determining the commit id used
Agreed, as usual cleaning up messes is much harder than avoiding making them in the first place.
But I still think it's a pity that in our quest to let people work locally in a versioned manner (which is a GOOD thing) we seem to have lost the ability to easilly track how "what was at the heads of branches in the main repository" changed over time.
what Valve does with the Source engine stuff where parts of it are released
s/does/did/
Valve has been somewhat inconsistent with releasing gamecode source. They released gamecode source for a while for the hl2 branch (which afaict covered portal too) but stopped after the 2007 release (so no mac support in sourcecode level mods). Apparently they did release gamecode source for the alien swarm branch but not for either left for dead or portal 2.
Just read the docs and it seems that lets you see the history of a branch within your local repository. Is there any way to do the same for a remote repository?
It seems at odds with the trend they have had of reducing pin count on cpu package as of late.
Umm mainstream desktop CPUs do seem to have gone down in pin count but only marginally (1156 to 1155 with the next generation supposedly on 1150). Meanwhile high end desktop CPUs have gone up from 1366 pins to 2011 pins.
My experiance with git (admittedly i'm something of a git newbie so PLEASE tell me if there is an easy answer to this) is that if you don't have the commit ID for the version that was used for something it's very difficult to find it from other information. Particulally when you get developers who work on a modified version of something like linux in such a way that all the commits from upstream linux appear in their derviatives history.
Compounding this is the fact that git makes it awkward to find a commit's children.
Am I missing something? Is there something to trace what commits were at some point at the head of a particular branch in a particular repo rather than merely being imported as parents of the head that the developer pushed/pulled?
BTW this would be the Bus between the CPU and chipset. Hypertransport bus? I forget the term.
You are a little behind the times. The days of the CPU-chipset connection being the fastest one in the machine are gone on the intel side and probablly numbered on the AMD side.
The way computers used to be work is that there was a bus (known as the "front side bus" that connected the "northbridge" and the processor(s). The northbridge then contained the memory controller and fastest interfaces and was connected over a relatively low bandwidth link to the southbridge which did the lower speed work (ethernet, drive interfaces, PCI, narrow PCIe interfaces). Which interfaces were considered low speed and which were considered high speed and the interconnect between north and southbridges changed over the years as overall speeds increased but the northbridge-southbridge interface was always much slower than the CPU-northbridge interface.
However the front side bus system was starting to show it's limitations, particularly in multiprocessor setups. So when they introduced their opterons and athlon64s AMD moved to a system where the memory controller(s) were on the CPU(s) and the CPU(s) and chipset were connected with a system of point-point links known as hypertransport. Interfaces other than memory were still provided by the chipset which still generally contained two chips. Intel decided to stick with the conventional front side bus arrangement.
Some years later intel moved to an arrangement very similar to what AMD had done years earlier but using quickpath instead of hypertransport. However they only used this arrangement on high end desktop and server parts. The corresponding mainstream parts integrated 16 PCIe lanes into the CPU and the chipset was relegated to handling the former southbridge functions (ethernet, SATA, low lane count PCIe) and connected by a relatively low bandwidth interface. With the next generation intel high end desktop and server parts also moved to integrating high speed interfaces onto the CPU and using a relatively low speed link to the CHIPSET (quickpath stayed arround but only as an interface for interconnecting processors in multi CPU systems)
AMD still use a hypertransport connected chipset on their flagship desktop and server platforms but their lower end parts are using a more integrated design and I'd expect their higher end parts to follow when they finally decide to move on from the AM2/2+/3/3+ line.
mmm, compared to regular desktop PC hardware certainly.
and a great set of software tools to support them.
CPU support is fine but it's let down by the platform mess. Lots of arm hardware still needs vendor specific kernel patches to make all the hardware work and those patches often don't get updated to newer versions of the kernel. Even when you can use the upstream kernel source you often have to recompile it for each device familty.
I suspect it should be possible to make it work. The CPU features are there.
The one thing that may be a problem is the 3D graphics situation. 3D libraries on embedded boards are a bit of a mess and some messing arround and/or writing of shims may be needed to make things work together. I know you used to have to use a Pi specific method to get an openGL es context on the Pi. I don't know if that is still the case (I haven't been following that side of things myself).
Oracle java doesn't currently work on armv6 hard float. Openjdk with zero works but is SLOW Openjdk with jamvm works and seems to be the most workable option right now Openjdk with cacao is broken on all arm hardfloat platforms at the moment*. I haven't tried openjdk with shark or avian.
You mean the one that was recently on kickstarter? The one that was talking about 150 units?
We were able to go from Gerbers to shipping in about a month.
I can believe that. Presumablly all the parts you used (other than the PCB) were bought from stock. Some of them may have been tricky to find but once found presumablly buying them was reasonablly quick.
It has now been long enough, and the demand has been high enough, that this should be irrelevant.
I'd agree it's taken an annoyingly long time and that both the RPF and the manufacturing partners have made mistakes which have delayed things.
Still the backlog basically boils down to "how much are the companies who are paying for the manufacturing prepared to risk", not "how much work are the RPF prepared to do". So saying the RPF shouldn't work on other things while the backlog still exists is silly.
What good is a Raspberry Pi camera accessory when you can't get a Raspberry Pi?
There are now at least three vendors in the UK with the raspberry Pi in stock. Things don't seem so rosy in the US right now unfortunately though newark claim "1321 Expected to ship 26 Nov, 2012"
The foundation has its priorities all wrong. If they put half as much effort into the supply problems as they do on this neverending astroturfing
The trouble is with something like the Pi you can't just buy the components off the shelf. The manufacturing partners have to order the SoCs, wait for them to be produced and shipped to the PCB assembly factory, then get the boards made and shipped from where they produce them to where they want to sell them. That takes months so they have to guess how many boards they are going to sell months in advance of actually selling them.
If they guess too high then they have stock sitting on the shelves which locks up capital and which may lead to having to sell the units at a loss down the line. If they guess too low then they have pissed off potential customers like you.
Yeah, high resoloution CCDs and the electronics to drive them at film framerates have come down as semiconductor fabrication has improved and economys of scale have increased.
Having said that this is far from comparable with a proffesional tv or movie camera for a couple of reasons.
Firstly due to the lack of any high speed network or storage interfaces on the Pi and the lack of CPU power for custom processing you are pretty much forced to use the h.264 compressor in the GPU on the video before you can store or transmit it.
Secondly quality is highly impacted by the quality of the lens and the physical size of the sensor. This thing will have a tiny sensor and a cheap lens.
It also depends on where you are, here in the UK I can find three suppliers who claim to have stock but the US situation doesn't appear anywhere near as rosy.
I'm not sure you get what the problem is, the problem is that end users often don't "request secure pages" explicitly, they either type a plain domain name with no protocol or they follow a link from another site (possiblly a search engine) so the initial request for a session is often over plain http.
If the users connection is not subject to MITM then they get redirected to the secure site but if a MITM is present then the MITM can make sure that doesn't happen by rewriting any links or redirects that point to https sites back to plain http and then talking to the user over plain http while talking to the server over https.
This attempts to reduce the risk by making a sticky "this website must be secure flag", if the user always uses a compromised connection it won't help but in the more common case where a user uses an uncompromised connection most of the time and then occasionally uses compromised ones (think a laptop user that moves between many public wifi hotspots).
Slashdot Mirror
After Microsoft stopped to sell it four years ago?
Depends what you mean by "stopped to sell it"
Sure you can't buy a retail box that says "windows XP" on it or a computer whos license sticker says "windows XP" unless you find it old stock but you can still get OEM copies and volume licenses that include downgrade rights (though IIRC the OEMs are no longer allowed to sell it pre-downgraded, you have to downgrade yourself) and i'm pretty sure you can still buy XP for inclusion in embedded setups too.
I find that most of the time you can grab a source package from testing/unstable and build it on stable with only minor modifications (sometimes none at all) and get a usable package.
But ultimately yes someone has to do the work of preparing the software you want in a form that is suitable for what you are going to run it on before you can deploy it.
Personally given how cheap hard drives are nowadays (even after the flood) I'd question the point of compressing at rip time at all.
Ripping requires regular human attention so if your compression processes can't keep up with the ripping then i'd suggest just not compressing at rip time. If you want an encoded version for use on portable players you can do that as a batch job when you are not sitting in front of the machine.
So, like you said, it's all about duration and area.
And surrounding environment.
Trigger that spark plug in normal air and not much will happen.
Trigger it in an engine cylinder and the fuel-air mixture will ignite pushing the piston down with the cylinder wall containing the blast.
Trigger it in an room filled with the correct fuel-air mixture and boom
Their monopoly
According to wikipedia they lost their monoploy on instant photography in the USA in the mid 1990s as their patents expired and with them their ability to restrict where instax was sold.
dunno how much impact that had in the grand scheme of things though.
Afaict people generally withdraw relatively large denominations from the bank and then spend them in shops taking change in smaller denominations which they either spend back in the shops or put in a jar and take back to the bank.
So for dollar coins to become widespread they need to find their way into shop tills in significant numbers. For that to happen one of two things need to happen
1: shopkeepers decide to order dollar coins instead of dollar bills from the bank
2: the banks stop distributing dollar bills.
The plan was for the B to be released first as the intial release was aimed at early adoptors and developers, the model A would then follow soon afterwards.
However that was back when they throught demand for the Pi would be in the tens of thousands. With the manufacturing partners scrambling to meet demand (and being frustrated by SoC lead times) they did not want to divert SoCs away from model B production to model A production.
Now that the situation is starting to improve and stabalise they are finally bringing up the model A production (though how long it will be before they are readilly available is anyones guess).
Or rather it didn't route through it in the first place.
In europe and north america we have networks of overland fibers because we have sufficient political stability that people aren't worried that their links run through intervening countries. If germany or france (or even the netherlands) shut down all internet links it would cause a LOT of pain for internet users in europe and to a lesser extent across the world but noone is seriously worried about that happening.
OTOH in less stable parts of the world what you see is undersea cables hugging the coast with a landing point in every country they run past. If one country shuts down it's landing points noone else really cares.
And how many ISPs would suddenly get a lot more open in their peering policies if the option of using a teir 1 as a route of last resort went away?
I think to really "shut down the internet" the US would at least have to get the europeans to play along.
"need"? no
But if the exam gives me the choice between using a basic "scientific" calculator and using a "graphic" calculator i'm going to pick the latter. Having enough display space to enter a long sum and then check it was entered correctly is a killer feature IMO (though modern scientific calculators are much better than the old ones in this regard). The graphing functions are mostly useful as a quick sanity check or to get a rough feel for the shape of a function you were about to do some analysis on.
Never used the programming features myself. Writing a program before the exam and taking it in was considered cheating (the calculators were supposed to have their memory reset before the exam to prevent this though in practice it never actually happened) and I don't think there would have been time to write one during the actual exam.
Normally the proper solution is to actually include in a build some way of determining the commit id used
Agreed, as usual cleaning up messes is much harder than avoiding making them in the first place.
But I still think it's a pity that in our quest to let people work locally in a versioned manner (which is a GOOD thing) we seem to have lost the ability to easilly track how "what was at the heads of branches in the main repository" changed over time.
what Valve does with the Source engine stuff where parts of it are released
s/does/did/
Valve has been somewhat inconsistent with releasing gamecode source. They released gamecode source for a while for the hl2 branch (which afaict covered portal too) but stopped after the 2007 release (so no mac support in sourcecode level mods). Apparently they did release gamecode source for the alien swarm branch but not for either left for dead or portal 2.
Just read the docs and it seems that lets you see the history of a branch within your local repository. Is there any way to do the same for a remote repository?
It seems at odds with the trend they have had of reducing pin count on cpu package as of late.
Umm mainstream desktop CPUs do seem to have gone down in pin count but only marginally (1156 to 1155 with the next generation supposedly on 1150). Meanwhile high end desktop CPUs have gone up from 1366 pins to 2011 pins.
My experiance with git (admittedly i'm something of a git newbie so PLEASE tell me if there is an easy answer to this) is that if you don't have the commit ID for the version that was used for something it's very difficult to find it from other information. Particulally when you get developers who work on a modified version of something like linux in such a way that all the commits from upstream linux appear in their derviatives history.
Compounding this is the fact that git makes it awkward to find a commit's children.
Am I missing something? Is there something to trace what commits were at some point at the head of a particular branch in a particular repo rather than merely being imported as parents of the head that the developer pushed/pulled?
BTW this would be the Bus between the CPU and chipset. Hypertransport bus? I forget the term.
You are a little behind the times. The days of the CPU-chipset connection being the fastest one in the machine are gone on the intel side and probablly numbered on the AMD side.
The way computers used to be work is that there was a bus (known as the "front side bus" that connected the "northbridge" and the processor(s). The northbridge then contained the memory controller and fastest interfaces and was connected over a relatively low bandwidth link to the southbridge which did the lower speed work (ethernet, drive interfaces, PCI, narrow PCIe interfaces). Which interfaces were considered low speed and which were considered high speed and the interconnect between north and southbridges changed over the years as overall speeds increased but the northbridge-southbridge interface was always much slower than the CPU-northbridge interface.
However the front side bus system was starting to show it's limitations, particularly in multiprocessor setups. So when they introduced their opterons and athlon64s AMD moved to a system where the memory controller(s) were on the CPU(s) and the CPU(s) and chipset were connected with a system of point-point links known as hypertransport. Interfaces other than memory were still provided by the chipset which still generally contained two chips. Intel decided to stick with the conventional front side bus arrangement.
Some years later intel moved to an arrangement very similar to what AMD had done years earlier but using quickpath instead of hypertransport. However they only used this arrangement on high end desktop and server parts. The corresponding mainstream parts integrated 16 PCIe lanes into the CPU and the chipset was relegated to handling the former southbridge functions (ethernet, SATA, low lane count PCIe) and connected by a relatively low bandwidth interface. With the next generation intel high end desktop and server parts also moved to integrating high speed interfaces onto the CPU and using a relatively low speed link to the CHIPSET (quickpath stayed arround but only as an interface for interconnecting processors in multi CPU systems)
AMD still use a hypertransport connected chipset on their flagship desktop and server platforms but their lower end parts are using a more integrated design and I'd expect their higher end parts to follow when they finally decide to move on from the AM2/2+/3/3+ line.
And, enter ARM. Fast CPUs,
For sufficiently small definitions of fast.
tiny power consumption,
mmm, compared to regular desktop PC hardware certainly.
and a great set of software tools to support them.
CPU support is fine but it's let down by the platform mess. Lots of arm hardware still needs vendor specific kernel patches to make all the hardware work and those patches often don't get updated to newer versions of the kernel. Even when you can use the upstream kernel source you often have to recompile it for each device familty.
I suspect it should be possible to make it work. The CPU features are there.
The one thing that may be a problem is the 3D graphics situation. 3D libraries on embedded boards are a bit of a mess and some messing arround and/or writing of shims may be needed to make things work together. I know you used to have to use a Pi specific method to get an openGL es context on the Pi. I don't know if that is still the case (I haven't been following that side of things myself).
Quick summary of the java situation on raspbian:
Oracle java doesn't currently work on armv6 hard float.
Openjdk with zero works but is SLOW
Openjdk with jamvm works and seems to be the most workable option right now
Openjdk with cacao is broken on all arm hardfloat platforms at the moment*.
I haven't tried openjdk with shark or avian.
* see debian bugs 688703 and 688702
I handled the manufacturing for the P112 project.
You mean the one that was recently on kickstarter? The one that was talking about 150 units?
We were able to go from Gerbers to shipping in about a month.
I can believe that. Presumablly all the parts you used (other than the PCB) were bought from stock. Some of them may have been tricky to find but once found presumablly buying them was reasonablly quick.
It has now been long enough, and the demand has been high enough, that this should be irrelevant.
I'd agree it's taken an annoyingly long time and that both the RPF and the manufacturing partners have made mistakes which have delayed things.
Still the backlog basically boils down to "how much are the companies who are paying for the manufacturing prepared to risk", not "how much work are the RPF prepared to do". So saying the RPF shouldn't work on other things while the backlog still exists is silly.
What good is a Raspberry Pi camera accessory when you can't get a Raspberry Pi?
There are now at least three vendors in the UK with the raspberry Pi in stock. Things don't seem so rosy in the US right now unfortunately though newark claim "1321 Expected to ship 26 Nov, 2012"
The foundation has its priorities all wrong. If they put half as much effort into the supply problems as they do on this neverending astroturfing
The trouble is with something like the Pi you can't just buy the components off the shelf. The manufacturing partners have to order the SoCs, wait for them to be produced and shipped to the PCB assembly factory, then get the boards made and shipped from where they produce them to where they want to sell them. That takes months so they have to guess how many boards they are going to sell months in advance of actually selling them.
If they guess too high then they have stock sitting on the shelves which locks up capital and which may lead to having to sell the units at a loss down the line. If they guess too low then they have pissed off potential customers like you.
Yeah, high resoloution CCDs and the electronics to drive them at film framerates have come down as semiconductor fabrication has improved and economys of scale have increased.
Having said that this is far from comparable with a proffesional tv or movie camera for a couple of reasons.
Firstly due to the lack of any high speed network or storage interfaces on the Pi and the lack of CPU power for custom processing you are pretty much forced to use the h.264 compressor in the GPU on the video before you can store or transmit it.
Secondly quality is highly impacted by the quality of the lens and the physical size of the sensor. This thing will have a tiny sensor and a cheap lens.
It also depends on where you are, here in the UK I can find three suppliers who claim to have stock but the US situation doesn't appear anywhere near as rosy.
One thing that comes to mind is that afaict win64 is the only common platform where sizeof(long) != sizeof(void *).
I dunno if this is the reason for firefox's problems though or if it's just a case of noone caring to debug it.
I'm not sure you get what the problem is, the problem is that end users often don't "request secure pages" explicitly, they either type a plain domain name with no protocol or they follow a link from another site (possiblly a search engine) so the initial request for a session is often over plain http.
If the users connection is not subject to MITM then they get redirected to the secure site but if a MITM is present then the MITM can make sure that doesn't happen by rewriting any links or redirects that point to https sites back to plain http and then talking to the user over plain http while talking to the server over https.
This attempts to reduce the risk by making a sticky "this website must be secure flag", if the user always uses a compromised connection it won't help but in the more common case where a user uses an uncompromised connection most of the time and then occasionally uses compromised ones (think a laptop user that moves between many public wifi hotspots).