Be aware that there is a reason that ssh asks for a "passphrase". Encyrption passwords must have much more entropy than login passwords because the only thing restricting the number of attempts the attacker may make is the amount of computing power the attacker has at their disposal.
I bet there are a lot of ssh keys out there with passwords that ammount to nothing more than a false sense of security.
microcontrollers don't run linux though. Linux requires a MMU and a megabyte or so of memory neither of which microcontrollers have.
The question is do them68K/CF chips that can run linux offer any compelling advantage over arm or mips soloutions that would make up for the far lower software support?
the vast majority of C structures are also C++ structures and will end up with the same binary representation in both.
Making a header for a C library that can be used in both C programs C++ programs is basically a matter of adding a bit of boilerplate at the start and end and avoiding some of the hariest C constructs. The ease of doing so and the popularity of C++ combine to make the vast majority of C libraries available to C++ coders with nothing more than a #include.
Whereas with most other languages even if they support efficient direct calls to C functions* you have to completely rewrite the function declarations and data structure definions and hope you got the mappings right so that the types match up in a portable manner. Sometimes there are automatic converters but in my experience they have trouble handling all but the simplest cases.
* Java for example doesn't, they expect you to write a C or C++ wrapper to interface between native and java code. There is a third party hack called JNA but IIRC it comes at a severe performance cost.
1: to allow for references which you need to stay arround as long as the object exists but you don't want them to keep the object in existance. 2: when you are using a memory management model (typically reference counting) that cannot clean up cycles of garbage and therefore requires you to avoid creating cycles in any structure that could become garbage.
Afaict point 2 forces you to make a lot of pointers "artifically weak" to avoid cycles which in turn means you have to be very careful to keep a reference around to the root of a data structure to keep parts of it from being freed too early. That is the price you pay for using automatic reference counting as your memory management strategy.
Of course tracing GCs have their own problems. Afaict the reason java runs with a low memory limit by default is to make sure that the gc is forced to run before the program eats up too much memory and drives the system into swap death.
Since only the most powerful servers have it I see it as offering no real advantage. XP users use PAE to go around the 4 gig limit hack anyway. So if I had 4 gigs of ram it would not matter if the OS is 32-bit or 64-bit. The memory addresses would be the same. If I had 8 gigs of ram I would have it extended if I ran XP with PAE so I would have an identical amount of memory addresses in either case.
Leaving aside the fact that recent desktop versions of 32-bit windows (starting with XP SP2) are gimped to only allow 4GB of physical address space even when in PAE mode it's not physical addresses that matter for this attack, it's how the size of VIRTUAL address space compares with the amount of ram.
Suppose that the hacker has an exploit that lets him make the program run some bytecode from a address he specifies without applying security checks to it but can't find out before running the exploit where anything is in memory.
In a 32-bit app there is 2-4GB of usable virtual address space and modern systems have enough ram to map all of that virtual address space to memory. So a malicious script can fill a significant proportion of the virtual address space with it's crap and hence even with randomised addressing there can be a good chance of hitting a copy of the sprayed code when the CPU jumps to a fixed memory address.
In a 64-bit app running on current "64-bit"* PCs there is 140TB of virtual address space. No system on the market has enough ram to map more than a tiny fraction of this to memory. Therefore even if the attacker sprays enough copies of his code to fill physical memory he will still have only covered a tiny proportion of the apps virtual address space. If virtual addresses are randomised** then the exploit code is unlikely to hit a copy of the sprayed code when it jumps to a fixed memory address.
* Current "64-bit" PCs only have a 48 bit virtual address space and half of that is reseved for OS use leaving a 47 bit address space for apps. ** There is nothing that requires virtual addresses to have any correspondence to physical addresses. It's perfectly feasible to have a virtual address much higher than the highest physical address.
The N280 is also 32-bit only, so is the ULV celeron used in the original Eee PC. Intel didn't release a 64-bit capable netbook atom* until december 2009.
Now granted, the Z and E series Atoms do not all support 64-bit, but they are not intended for 'regular' computers.
It seems that Z series atoms were intended for "ultra mobile PCs" which afaict were even tinier than netbooks but still ran regular PC operations systems. Afaict ASUS did put a Z series atom in a netbook too.
* 64-bit capable nettop atoms appeared some time before this.
The GPs statement was
"All Intel/AMD CPUs sold in the past 6 years are 64-bit."
This is blatently untrue. Even if we limit it to intel/AMD CPUs in products intended to run a regular windows or "desktop linux" operating system it's STILL blatantly untrue.
It depends which 16-bit mode you are talking about.
It IS possible to do 16-bit protected mode (which win16 apps use) while in long mode. Wine has no trouble doing it. MS just couldn't be bothered debugging WOW on top of WOW64 so they left it out.
OTOH it is not possible to do virtual 8086 mode while in long mode.
And I'm sure most "data centers" of the early Internet would love to have the 60/60 Mbit line that I have at home on a plain residential fiber connection,
What does their policy say about activities like running servers? is there a "fair use policy"*?
Who needs the data center?
Those who want proper static IPs with advance warning and parelell running periods if they do have to be changed, high reliability (afaict "broadband" is at the bottom of the the repair priority list for telcos), more bandwidth (especially upstream bandwidth) than they can affordably get at their own premises.
Latest stats from Norway now is that the average broadband is 14.8 Mbit/s and the mean 7.9 Mbit/s
Are those upload speeds or download speeds? (i'd guess download speeds).
Most solar panels end up in small installations, where they compete at the small consumer price levels.
Which will work for a while.
But ultimately in a situation dominated by local generation power company charging models will have to change. The service of moving power around will still be needed and will still have to be paid for even if most customers generate as much as they use on average.
The real problem is andriod's permission system is broken. Specifically there are two major problems.
1: there is no way for a user to go through the permissions an app wants and decide what permissions it shoudl actually get. 2: there are some privilages apps simply can't get though the normal permissions system even though them would allow the app to be more useful.
"Rooting" works arround problem 2 and I belive can allow the installation of apps that attempt to solve problem 1
Generally if a UK collage or university is prepared to take you the government will give you a visa to come and study. The government is quite happy to have people from across the world buy education from us.
However in recent years there has been a scandal surrounding abuse of these visas. People would sign up for an educational institution (often but not always a sham collage that existed for the purpose) get a student visa and come to the UK but rather than actually studying they go and find illegal work. For a visa abuser student visas had the advantage over tourist visas that a student can legitimately stay in the country for a long time so someone abusing a student visa could come and go from the country without arousing suspicion.
The result has been a government clampdown. Educational institutions are now required to keep track of non-EU students and report those who fail to attend to the border agency (who I presume will cancel the visa). Educational institutions which fail to do this can lose the ability to sponsor visas for non-EU students and hence practically speaking lose the ability to take them. For a typical UK university losing the ability to take non-EU students would be a MASSIVE financial blow and it would not surprise me if for some universities it led to bankruptcy. London Metropolitan University got caught up in this and has come very close to losing the ability to take foreign students, apparently they have won a reprieve for now but the threat is very real http://www.guardian.co.uk/education/2012/sep/21/london-metropolitan-university-reprieve-student-visa .
This is the first i've heard of a university using biometrics to keep tabs on students though. The impression I got from the unveristy i'm at was that checking student ID cards was considered sufficient.
Please separate the requirements of their browsers from the requirements of their servers.
You can only deploy something if it works with your clients. Practically speaking for a public facing web server that means supporting all common* client setups**. For the moment neither SNI or IPv6 has sufficiently wide support in client setups to make deploying it on a public facing website reasonable. Therefore the only reasonable way to deploy SSL on a public facing website at the moment is to have a dedicated IPv4 address for each certificate which given the current IPv4 address shortage means that bottom of the barrel web hosting plans won't be doing it.
I expect SNI support to become ubiquitous before IPv6 support and connectivity does but I could be wrong.
Profound difficulties occur when supporting the name-based virtual servers for people and software _who refuse to follow the best practices_. The results can be nightmarish. If I, as a user, use "www.example.com" instead of "example.com" and they're both at the same IP address, I can often wind up with completely different web pages and little hint of what I did wrong, and then call tech support about the problem.
That could probably be avoided by having a policy of configuring servers to respond to both the bare domain and www. in the same way unless specifically requested otherwise.
There is also the very confusing behavior when common software configurations start putting IP address "127.0.0.1" and "::1" in the webserver's/etc/hosts with the fully qualified hostname. This is actually quite common, but it means that the web server itself can't reliably detect whether the web server is running properly running. Going to the IP address by typing it directly is not necessarily the same virtual host, and redirects will go to the/etc/hosts specified "127.0.0.1". This makes testing the primary web service from the same host itself quite chaotic.
I can see that being a problem in situations involving mixed name based and IP based virtual hosting. Still it's an easy enough one to avoid once you know about it. It's probablly best to avoid having a machine's primary name reflect one of the names it hosts anyway as it can make things very confusing if services move around.
The IP based virtual hosting not only allows far easier management of these configurations, it allows vastly simplified packet analysis to trace and analyze the virtual host specific network traffic.
Yes I can see that.
Still I don't think requiring a bit more care to deploy correctly is synonymous with "never worked well"
For that reasoon alone, I urge partners and colleagues to switch to IPv6 IP based virtual hosts for crowded externally facing virtual hosts
Are you saying you advocate people run public websites on IPv6 only today? (thus making them inaccessible to a substantial fraction of internet users) Are you saying that if SNI and IPv6 support were both ubiquitous among the clients you are interested in you'd advocate using IPv6 than SNI? (IMO this is perfectly reasonable but for public websites it's a long way off)
*exactly where you draw the threshold of "common" depends on how many users you are prepared to lose **Where setup includes the browser, the OS, the internet connection etc.
A simple binary tree has similar problems to a simple hash table. Namely that by controlling the items that are added to the strucuture it's possible to effectively turn it into a list (in a hash table you do it by putting everything in one bucket, in a binary tree you do it by making sure that each node you add ends up as a child of the previous node you added).
Of course there are countermeasures against this attack on binary trees just like there are countermeasures against attacks on hash tables.
Also, ZFS is an insane thing written by people who don't seem to understand that keeping a good separation of concerns can lead to a rather slick set of general tools that can be used on almost any fs.
Separating stuff into layers has benefits but it also has costs. Sometimes merging layers can make things practical that aren't practical with them separate. Afaict this is what drove the creation of zfs and btrfs.
Lets first look at RAID. traditional raid provides protection against reads that fail but not against reads that silently return wrong data. Experience has shown that hard drives cannot be trusted not to silently return wrong data. Worse still raid resyncs after power failure may silently overwrite good data with corrupt data. Adding checksums in the raid layer is difficult because there is nowhere good to put them (you can't just make the blocks slightly smaller because filesystems expect power of two block sizes). Putting checksums in the filesystem helps a bit but even if there is an API to request the "other copy" when the filesystem detects corrupt data the aforementioned resync may have already overwritten the good version with the bad one. By moving the responsibility for storing data redundantly into the filesystem we can avoid this problem, when going a consistency check the filesystem can check both copies against the checksum it keeps and ensure it overwrites the bad version with the good one rather than vice-versa
Also traditional raid requires the whole array to have the same level of redundancy. It's possible to work around this by having multiple arrays but that then means you have to manually allocate space between the arrays. Yes there are ways to grow and shrink arrays but it's extra work and may involve downtime. With redundancy at the filesystem layer you should just be able to tell the filesystem what level of redundancy you want for each directory and let the free space be used for any of them.
Now lets consider snapshots. Snapshots below the fileystem layer mean that you waste effort snapshotting free space. Worse still if writing to a snapshoted volume works by remapping blocks then it creates fragmentation in the mapping which is likely to stay around forever. This fragmentation happens even if the blocks were previously free (due to the fact we are snapshoting free space) and may stick around even after the file that caused it to happen is long gone. With snapshots at the filesystem level you don't snapshot free space and while you still get fragmentation you only get it when modifying an existing file (not when creating a new file) and it goes away when the file is deleted. Finally having snapshots at the filesystem layer means you don't have to snapshot the whole filesystem, you can snapshot individual directories within it.
Now lets consider dedupe if you do it below the filesystem layer then to get much benefit from it you have to make your logical devices larger (in aggregate) than your physical devices. That is likely to lead to some very strange errors when you run out of physical blocks but the filesystems still think they have free space. It can also lead to the problem of "garbage" that the dedupe layer thinks needs to be preserved even though it's not actually in use by the filsystem (granted a trim-like API between the filesystem and the dedupe layer could fix this).
With encyrption having encryption as part of the filesystem allows you to chose what you do and don't want encrypted without having to mess arround with seperate volumes and the administrative overhead threof (see previous comments about raid) though how useful this is and whether it is worth the increased risk (too easy to leave clues behind unencyrpted) depends hugely on your threat model.
I'd bet that most users who don't have SNI supporting browsers don't have access to IPv6 servers either. IIRC IPv6 on windows XP is turned off by default which for most users means it may as well not be there.
instead of the amazing crap that is server name based virtual hosting and which has *never* worked well.
I've been using it for years with no problems. If you are going to claim something that is used by almost every hosting provider on the planet and by many private servers too has "never worked well" you'd better come up with some convincing evidence.
Avoiding the guesswork, rewriting, and redirecting rules of name based virtual hosting is one of the best justifications I know for using IPv6.
umm at least with apache there doesn't seem to be much difference. With IP based vitual hosting you tell it what IP you want to go with each site. With name based virtual hosting you tell it a list of names to go with each site.
You didn't complain about their hands on your traffic when you accessed the Netflix content which they have locally cached on their servers, courtesy of Netflix and Akamai.
That doesn't require any "meddling", it's up to a website operator (and their contractors if relevant) to decide where to deliver content from, if they choose to host servers with the customer's ISP that is their prerogative,
OTOH if cox is messing with the packets to put in a caching system without netflix's cooperation then that is bad.
And you didn't complain when they used traffic shaping to send your requests for un-cached Netflix data not over their general Internet peering links, but rather across a dedicated link where they peer directly with Netflix.
Why would they need to use "traffic shaping"? normal internet routing protocols should do this just fine!
IMO an ISPs job is to get your packets to/from the entity you are communicating with quickly, cheaply and unmolested. If two entities (ISPs or otherwise) determine that traffic between them (whether generated by themselves or by their customers) is heavy enough to justify a dedicated link then setting one up is a normal and expected thing to do not "meddling".
I'm just pointing out that nobody seems to have any problem with the "meddling" when it gives them a performance advantage over that of a plain old unmolested bit stream.
I've seen quite a few complaints about the way mobile internet providers often recompress images. That gives a performance boost but it comes at the price of making websites look ugly and possibly causing more serious problems for other applications. Ultimately people are only going to complain about something if they notice it and people are only going to notice something if it causes them problems. That is just human nature.
Sadly while big customers can negotiate contract terms that require an unmolested connection retail customers usually don't have enough leverage to do that so if meddling causes problems their only real options are to either put up with it, switch to another ISP who could do the same thing at any time (and that is assuming there even is another reasonable ISP choice in the area) or use a tunnelling solution (which shields the packets from the meddling but adds latency, cost and an extra point of failure).
AIUI the problem is that while the SoC theoreticallly supports 1 gigabyte of ram noone actually makes an 8 gigabit* chip that is compatible with the memory interface on the SoC they are using.
I suspect that at some point there will be a second gen Pi with a different SoC, a newer memory technology and more memory but I wouldn't expect it any time soon.
*Don't ask me why system memory is typically measured in gigabytes while memory chips are measured in gigabits but that seems to be the way things are.
There is no way for the inverter to tell why it lost it's connection to the grid so when it loses it's connection the inverter has to assume the worst and shut down to protect people (both those working on the domestic electricity installation and those working on the distribution network outside).
It would be possible to design an inverter system that avoided this by having two seperate ports and connecting it between the incoming supply and the houses distribution system but this would make the device both more expensive (need more high power switching stuff) and harder to install.
1: countries "own" their airspace. 2: when things go wrong in flight all signigifant parts of the craft tend to ends up on the ground pretty quickly (whether in one peice or several). 3: everything moves at fairly slow speeds relative to the air
The result is functional objects are well-tracked, we don't have an "air junk" problem and while we may have a few military planes operating outside the usual rules outside of warzones even those are likely to be coordinated with the civilian traffic..
In space junk tends to stay there for years in low orbits and practically forever in high orbits. Thanks to the mechanics of orbit it is possible to have two stable orbits with massively different velocities crossing the same point meaning even very small peices of junk can cause a lot of damage. We do track the functioning sattelites (those that aren't secret anyway) and try to track the larger peices of junk but the small peices just can't reasonablly be tracked and the tracking isn't a perfect process even for larger objectw.
If your computer consumes X-watts, it's advisable to fit a PSU that can pump out almost 2X the wattage.
Unless you are buying crap from manufacturers who fraudulently rate their PSUs that is BS.
It is true that PSUs are most efficient at arround 50% of max load. However most PCs don't draw anything like their maximum power most of the time. So if you pick your PSU based on your PCs maximum load plus a reasonable safety margin you will probablly find it is running at less than 50% load most of the time.
If a 600 watt PSU - an above-average size - is running at full load and is 80% efficient at full load, then it is wasting 120 watts FTFY
120 watts is quite a bit IF you are wasting it 24/7 even in places with relatively cheap electricity a watt of 2/47 use costs about a dollar a year and saving half of that by going from basic 80 plus to 80 plus platinum could save enough money to pay for replacing the PSU in a couple of years. The thing is most peoples computers don't draw anywhere near that much power most of the time
Slashdot Mirror
Be aware that there is a reason that ssh asks for a "passphrase". Encyrption passwords must have much more entropy than login passwords because the only thing restricting the number of attempts the attacker may make is the amount of computing power the attacker has at their disposal.
I bet there are a lot of ssh keys out there with passwords that ammount to nothing more than a false sense of security.
microcontrollers don't run linux though. Linux requires a MMU and a megabyte or so of memory neither of which microcontrollers have.
The question is do them68K/CF chips that can run linux offer any compelling advantage over arm or mips soloutions that would make up for the far lower software support?
the vast majority of C structures are also C++ structures and will end up with the same binary representation in both.
Making a header for a C library that can be used in both C programs C++ programs is basically a matter of adding a bit of boilerplate at the start and end and avoiding some of the hariest C constructs. The ease of doing so and the popularity of C++ combine to make the vast majority of C libraries available to C++ coders with nothing more than a #include.
Whereas with most other languages even if they support efficient direct calls to C functions* you have to completely rewrite the function declarations and data structure definions and hope you got the mappings right so that the types match up in a portable manner. Sometimes there are automatic converters but in my experience they have trouble handling all but the simplest cases.
* Java for example doesn't, they expect you to write a C or C++ wrapper to interface between native and java code. There is a third party hack called JNA but IIRC it comes at a severe performance cost.
AIUI there are two reasons to use weak pointers
1: to allow for references which you need to stay arround as long as the object exists but you don't want them to keep the object in existance.
2: when you are using a memory management model (typically reference counting) that cannot clean up cycles of garbage and therefore requires you to avoid creating cycles in any structure that could become garbage.
Afaict point 2 forces you to make a lot of pointers "artifically weak" to avoid cycles which in turn means you have to be very careful to keep a reference around to the root of a data structure to keep parts of it from being freed too early. That is the price you pay for using automatic reference counting as your memory management strategy.
Of course tracing GCs have their own problems. Afaict the reason java runs with a low memory limit by default is to make sure that the gc is forced to run before the program eats up too much memory and drives the system into swap death.
Since only the most powerful servers have it I see it as offering no real advantage. XP users use PAE to go around the 4 gig limit hack anyway. So if I had 4 gigs of ram it would not matter if the OS is 32-bit or 64-bit. The memory addresses would be the same. If I had 8 gigs of ram I would have it extended if I ran XP with PAE so I would have an identical amount of memory addresses in either case.
Leaving aside the fact that recent desktop versions of 32-bit windows (starting with XP SP2) are gimped to only allow 4GB of physical address space even when in PAE mode it's not physical addresses that matter for this attack, it's how the size of VIRTUAL address space compares with the amount of ram.
Suppose that the hacker has an exploit that lets him make the program run some bytecode from a address he specifies without applying security checks to it but can't find out before running the exploit where anything is in memory.
In a 32-bit app there is 2-4GB of usable virtual address space and modern systems have enough ram to map all of that virtual address space to memory. So a malicious script can fill a significant proportion of the virtual address space with it's crap and hence even with randomised addressing there can be a good chance of hitting a copy of the sprayed code when the CPU jumps to a fixed memory address.
In a 64-bit app running on current "64-bit"* PCs there is 140TB of virtual address space. No system on the market has enough ram to map more than a tiny fraction of this to memory. Therefore even if the attacker sprays enough copies of his code to fill physical memory he will still have only covered a tiny proportion of the apps virtual address space. If virtual addresses are randomised** then the exploit code is unlikely to hit a copy of the sprayed code when it jumps to a fixed memory address.
* Current "64-bit" PCs only have a 48 bit virtual address space and half of that is reseved for OS use leaving a 47 bit address space for apps.
** There is nothing that requires virtual addresses to have any correspondence to physical addresses. It's perfectly feasible to have a virtual address much higher than the highest physical address.
The exception is the N270, one of the first Atoms
The N280 is also 32-bit only, so is the ULV celeron used in the original Eee PC. Intel didn't release a 64-bit capable netbook atom* until december 2009.
Now granted, the Z and E series Atoms do not all support 64-bit, but they are not intended for 'regular' computers.
It seems that Z series atoms were intended for "ultra mobile PCs" which afaict were even tinier than netbooks but still ran regular PC operations systems. Afaict ASUS did put a Z series atom in a netbook too.
* 64-bit capable nettop atoms appeared some time before this.
The GPs statement was
"All Intel/AMD CPUs sold in the past 6 years are 64-bit."
This is blatently untrue. Even if we limit it to intel/AMD CPUs in products intended to run a regular windows or "desktop linux" operating system it's STILL blatantly untrue.
It depends which 16-bit mode you are talking about.
It IS possible to do 16-bit protected mode (which win16 apps use) while in long mode. Wine has no trouble doing it. MS just couldn't be bothered debugging WOW on top of WOW64 so they left it out.
OTOH it is not possible to do virtual 8086 mode while in long mode.
Windows is the only OS that is not 64-bit only.
bullshit.
And I'm sure most "data centers" of the early Internet would love to have the 60/60 Mbit line that I have at home on a plain residential fiber connection,
What does their policy say about activities like running servers? is there a "fair use policy"*?
Who needs the data center?
Those who want proper static IPs with advance warning and parelell running periods if they do have to be changed, high reliability (afaict "broadband" is at the bottom of the the repair priority list for telcos), more bandwidth (especially upstream bandwidth) than they can affordably get at their own premises.
Latest stats from Norway now is that the average broadband is 14.8 Mbit/s and the mean 7.9 Mbit/s
Are those upload speeds or download speeds? (i'd guess download speeds).
Most solar panels end up in small installations, where they compete at the small consumer price levels.
Which will work for a while.
But ultimately in a situation dominated by local generation power company charging models will have to change. The service of moving power around will still be needed and will still have to be paid for even if most customers generate as much as they use on average.
The real problem is andriod's permission system is broken. Specifically there are two major problems.
1: there is no way for a user to go through the permissions an app wants and decide what permissions it shoudl actually get.
2: there are some privilages apps simply can't get though the normal permissions system even though them would allow the app to be more useful.
"Rooting" works arround problem 2 and I belive can allow the installation of apps that attempt to solve problem 1
Actually it's the opposite.
Generally if a UK collage or university is prepared to take you the government will give you a visa to come and study. The government is quite happy to have people from across the world buy education from us.
However in recent years there has been a scandal surrounding abuse of these visas. People would sign up for an educational institution (often but not always a sham collage that existed for the purpose) get a student visa and come to the UK but rather than actually studying they go and find illegal work. For a visa abuser student visas had the advantage over tourist visas that a student can legitimately stay in the country for a long time so someone abusing a student visa could come and go from the country without arousing suspicion.
The result has been a government clampdown. Educational institutions are now required to keep track of non-EU students and report those who fail to attend to the border agency (who I presume will cancel the visa). Educational institutions which fail to do this can lose the ability to sponsor visas for non-EU students and hence practically speaking lose the ability to take them. For a typical UK university losing the ability to take non-EU students would be a MASSIVE financial blow and it would not surprise me if for some universities it led to bankruptcy. London Metropolitan University got caught up in this and has come very close to losing the ability to take foreign students, apparently they have won a reprieve for now but the threat is very real http://www.guardian.co.uk/education/2012/sep/21/london-metropolitan-university-reprieve-student-visa .
This is the first i've heard of a university using biometrics to keep tabs on students though. The impression I got from the unveristy i'm at was that checking student ID cards was considered sufficient.
Please separate the requirements of their browsers from the requirements of their servers.
You can only deploy something if it works with your clients. Practically speaking for a public facing web server that means supporting all common* client setups**. For the moment neither SNI or IPv6 has sufficiently wide support in client setups to make deploying it on a public facing website reasonable. Therefore the only reasonable way to deploy SSL on a public facing website at the moment is to have a dedicated IPv4 address for each certificate which given the current IPv4 address shortage means that bottom of the barrel web hosting plans won't be doing it.
I expect SNI support to become ubiquitous before IPv6 support and connectivity does but I could be wrong.
Profound difficulties occur when supporting the name-based virtual servers for people and software _who refuse to follow the best practices_. The results can be nightmarish. If I, as a user, use "www.example.com" instead of "example.com" and they're both at the same IP address, I can often wind up with completely different web pages and little hint of what I did wrong, and then call tech support about the problem.
That could probably be avoided by having a policy of configuring servers to respond to both the bare domain and www. in the same way unless specifically requested otherwise.
There is also the very confusing behavior when common software configurations start putting IP address "127.0.0.1" and "::1" in the webserver's /etc/hosts with the fully qualified hostname. This is actually quite common, but it means that the web server itself can't reliably detect whether the web server is running properly running. Going to the IP address by typing it directly is not necessarily the same virtual host, and redirects will go to the /etc/hosts specified "127.0.0.1". This makes testing the primary web service from the same host itself quite chaotic.
I can see that being a problem in situations involving mixed name based and IP based virtual hosting. Still it's an easy enough one to avoid once you know about it. It's probablly best to avoid having a machine's primary name reflect one of the names it hosts anyway as it can make things very confusing if services move around.
The IP based virtual hosting not only allows far easier management of these configurations, it allows vastly simplified packet analysis to trace and analyze the virtual host specific network traffic.
Yes I can see that.
Still I don't think requiring a bit more care to deploy correctly is synonymous with "never worked well"
For that reasoon alone, I urge partners and colleagues to switch to IPv6 IP based virtual hosts for crowded externally facing virtual hosts
Are you saying you advocate people run public websites on IPv6 only today? (thus making them inaccessible to a substantial fraction of internet users)
Are you saying that if SNI and IPv6 support were both ubiquitous among the clients you are interested in you'd advocate using IPv6 than SNI? (IMO this is perfectly reasonable but for public websites it's a long way off)
*exactly where you draw the threshold of "common" depends on how many users you are prepared to lose
**Where setup includes the browser, the OS, the internet connection etc.
A simple binary tree has similar problems to a simple hash table. Namely that by controlling the items that are added to the strucuture it's possible to effectively turn it into a list (in a hash table you do it by putting everything in one bucket, in a binary tree you do it by making sure that each node you add ends up as a child of the previous node you added).
Of course there are countermeasures against this attack on binary trees just like there are countermeasures against attacks on hash tables.
Also, ZFS is an insane thing written by people who don't seem to understand that keeping a good separation of concerns can lead to a rather slick set of general tools that can be used on almost any fs.
Separating stuff into layers has benefits but it also has costs. Sometimes merging layers can make things practical that aren't practical with them separate. Afaict this is what drove the creation of zfs and btrfs.
Lets first look at RAID. traditional raid provides protection against reads that fail but not against reads that silently return wrong data. Experience has shown that hard drives cannot be trusted not to silently return wrong data. Worse still raid resyncs after power failure may silently overwrite good data with corrupt data. Adding checksums in the raid layer is difficult because there is nowhere good to put them (you can't just make the blocks slightly smaller because filesystems expect power of two block sizes). Putting checksums in the filesystem helps a bit but even if there is an API to request the "other copy" when the filesystem detects corrupt data the aforementioned resync may have already overwritten the good version with the bad one. By moving the responsibility for storing data redundantly into the filesystem we can avoid this problem, when going a consistency check the filesystem can check both copies against the checksum it keeps and ensure it overwrites the bad version with the good one rather than vice-versa
Also traditional raid requires the whole array to have the same level of redundancy. It's possible to work around this by having multiple arrays but that then means you have to manually allocate space between the arrays. Yes there are ways to grow and shrink arrays but it's extra work and may involve downtime. With redundancy at the filesystem layer you should just be able to tell the filesystem what level of redundancy you want for each directory and let the free space be used for any of them.
Now lets consider snapshots. Snapshots below the fileystem layer mean that you waste effort snapshotting free space. Worse still if writing to a snapshoted volume works by remapping blocks then it creates fragmentation in the mapping which is likely to stay around forever. This fragmentation happens even if the blocks were previously free (due to the fact we are snapshoting free space) and may stick around even after the file that caused it to happen is long gone. With snapshots at the filesystem level you don't snapshot free space and while you still get fragmentation you only get it when modifying an existing file (not when creating a new file) and it goes away when the file is deleted. Finally having snapshots at the filesystem layer means you don't have to snapshot the whole filesystem, you can snapshot individual directories within it.
Now lets consider dedupe if you do it below the filesystem layer then to get much benefit from it you have to make your logical devices larger (in aggregate) than your physical devices. That is likely to lead to some very strange errors when you run out of physical blocks but the filesystems still think they have free space. It can also lead to the problem of "garbage" that the dedupe layer thinks needs to be preserved even though it's not actually in use by the filsystem (granted a trim-like API between the filesystem and the dedupe layer could fix this).
With encyrption having encryption as part of the filesystem allows you to chose what you do and don't want encrypted without having to mess arround with seperate volumes and the administrative overhead threof (see previous comments about raid) though how useful this is and whether it is worth the increased risk (too easy to leave clues behind unencyrpted) depends hugely on your threat model.
Or they can use IPv6 and IP based web servers
I'd bet that most users who don't have SNI supporting browsers don't have access to IPv6 servers either. IIRC IPv6 on windows XP is turned off by default which for most users means it may as well not be there.
instead of the amazing crap that is server name based virtual hosting and which has *never* worked well.
I've been using it for years with no problems. If you are going to claim something that is used by almost every hosting provider on the planet and by many private servers too has "never worked well" you'd better come up with some convincing evidence.
Avoiding the guesswork, rewriting, and redirecting rules of name based virtual hosting is one of the best justifications I know for using IPv6.
umm at least with apache there doesn't seem to be much difference. With IP based vitual hosting you tell it what IP you want to go with each site. With name based virtual hosting you tell it a list of names to go with each site.
You didn't complain about their hands on your traffic when you accessed the Netflix content which they have locally cached on their servers, courtesy of Netflix and Akamai.
That doesn't require any "meddling", it's up to a website operator (and their contractors if relevant) to decide where to deliver content from, if they choose to host servers with the customer's ISP that is their prerogative,
OTOH if cox is messing with the packets to put in a caching system without netflix's cooperation then that is bad.
And you didn't complain when they used traffic shaping to send your requests for un-cached Netflix data not over their general Internet peering links, but rather across a dedicated link where they peer directly with Netflix.
Why would they need to use "traffic shaping"? normal internet routing protocols should do this just fine!
IMO an ISPs job is to get your packets to/from the entity you are communicating with quickly, cheaply and unmolested. If two entities (ISPs or otherwise) determine that traffic between them (whether generated by themselves or by their customers) is heavy enough to justify a dedicated link then setting one up is a normal and expected thing to do not "meddling".
I'm just pointing out that nobody seems to have any problem with the "meddling" when it gives them a performance advantage over that of a plain old unmolested bit stream.
I've seen quite a few complaints about the way mobile internet providers often recompress images. That gives a performance boost but it comes at the price of making websites look ugly and possibly causing more serious problems for other applications. Ultimately people are only going to complain about something if they notice it and people are only going to notice something if it causes them problems. That is just human nature.
Sadly while big customers can negotiate contract terms that require an unmolested connection retail customers usually don't have enough leverage to do that so if meddling causes problems their only real options are to either put up with it, switch to another ISP who could do the same thing at any time (and that is assuming there even is another reasonable ISP choice in the area) or use a tunnelling solution (which shields the packets from the meddling but adds latency, cost and an extra point of failure).
AIUI the problem is that while the SoC theoreticallly supports 1 gigabyte of ram noone actually makes an 8 gigabit* chip that is compatible with the memory interface on the SoC they are using.
I suspect that at some point there will be a second gen Pi with a different SoC, a newer memory technology and more memory but I wouldn't expect it any time soon.
*Don't ask me why system memory is typically measured in gigabytes while memory chips are measured in gigabits but that seems to be the way things are.
I just wish the idiots would stop calling it a supercomputer. I don't belive that such exaggeration does the community any favors.
For sufficiently small definitions of "full web browser"
Netsurf runs pretty fast under linux too, the trouble is website compatibility is pretty poor.
IIRC it's x86 only and based on an aincient version of debian, i'm not sure i'd want to let such a thing near the internet.
There is no way for the inverter to tell why it lost it's connection to the grid so when it loses it's connection the inverter has to assume the worst and shut down to protect people (both those working on the domestic electricity installation and those working on the distribution network outside).
It would be possible to design an inverter system that avoided this by having two seperate ports and connecting it between the incoming supply and the houses distribution system but this would make the device both more expensive (need more high power switching stuff) and harder to install.
The thing with airplanes is
1: countries "own" their airspace.
2: when things go wrong in flight all signigifant parts of the craft tend to ends up on the ground pretty quickly (whether in one peice or several).
3: everything moves at fairly slow speeds relative to the air
The result is functional objects are well-tracked, we don't have an "air junk" problem and while we may have a few military planes operating outside the usual rules outside of warzones even those are likely to be coordinated with the civilian traffic..
In space junk tends to stay there for years in low orbits and practically forever in high orbits. Thanks to the mechanics of orbit it is possible to have two stable orbits with massively different velocities crossing the same point meaning even very small peices of junk can cause a lot of damage. We do track the functioning sattelites (those that aren't secret anyway) and try to track the larger peices of junk but the small peices just can't reasonablly be tracked and the tracking isn't a perfect process even for larger objectw.
If your computer consumes X-watts, it's advisable to fit a PSU that can pump out almost 2X the wattage.
Unless you are buying crap from manufacturers who fraudulently rate their PSUs that is BS.
It is true that PSUs are most efficient at arround 50% of max load. However most PCs don't draw anything like their maximum power most of the time. So if you pick your PSU based on your PCs maximum load plus a reasonable safety margin you will probablly find it is running at less than 50% load most of the time.
If a 600 watt PSU - an above-average size - is running at full load and is 80% efficient at full load, then it is wasting 120 watts
FTFY
120 watts is quite a bit IF you are wasting it 24/7 even in places with relatively cheap electricity a watt of 2/47 use costs about a dollar a year and saving half of that by going from basic 80 plus to 80 plus platinum could save enough money to pay for replacing the PSU in a couple of years. The thing is most peoples computers don't draw anywhere near that much power most of the time