11 base 2 (3) is prime, number of digits two which is prime.
Yes, that's just an example of what I said. 2, 3, 5, or 7 digits will give you prime numbers 3, 7, 31, and 127. But with 11 digits you get 2047 which is not a prime number.
But how many would contain all 1s? Answer that, and provide a proof for your answer, and you'll make math history.
Obviously the number of digits would have to be a prime number. But not all prime number of digits would give you a prime number. The first case is when there are 11 digits, the number would be 23*89 in that case.
That is just a case of a cure that is worse than the disease. It is pieces of javascript like that which is the reason why browsers allow you to disable javascript. Consider for example the case where you search for something in Google Images. When you click on an image, it takes you to a page from where you can either follow a link to the image or to the page it was found on. It also has a frame that serves as a preview of the page. Overall I like that UI, but the webpage inside that frame can break the UI by using javascript like you suggest. I see it happening all the time, and usually it takes you to a page that doesn't even contain the image you searched for. If you disable javascript, you won't have that kind of bad experience. But the main search results page in Google Images also uses javascript to format the results better for the size of your window. If you disable javascript Google Images doesn't render as nicely.
I know there exist browser extensions, that will allow the user to disable javascript on a per site basis. But I really don't think that is a good solution. First of all the existence of an extension is a lame excuse for not doing something sensible by default. Secondly I don't want to make such decisions on a per site basis. With javascript enabled for just some sites, you basically have to keep it off by default and just enable it for a few trusted sites. But you will get a worse experience because there are so many sites, that makes good use of javascript to make the page work just a little better.
What browsers should do is not to put restrictions on which sites can use javascript, but on what they can do with it. Letting a frame mess with the parent should not be permitted by default. But since in some rare cases it can be used in a good way, it should still be possible with cooperation from the parent frame.
Before anybody starts using TrueCrypt for encrypting data to be stored online, let me warn you, that TrueCrypt was not designed for that. Several years ago TrueCrypt switched to LRW because the encryption mode used before that was vulnerable to some watermarking attacks. However the LRW encryption was even more vulnerable in case an adversary is able to get a copy of the encrypted data from two different points in time. What that means is, that if you just have the encrypted container stored online using some networking file system, then whoever operates the server will have access to the encrypted data from any point in time. By comparing the data from different points in time, you can perform watermarking attacks. The same applies if you store your encrypted container locally but periodically put a backup of it on a server not directly controlled by you.
I mentioned above vulnerability to the TrueCrypt authors, but they didn't consider it a problem. However I think they did switch to a different mode later for other (less severe) reasons. I don't know if the new mode is better, but I doubt it. I have not yet seen any storage encryption specifically designed to handle this use case. Anything I have seen operating at the block layer TrueCrypt, cryptoloop, GBDE, etc. have been designed without considering the possibility that an adversary would have access to the encrypted data from two different points in time, in other words they are not suitable for storing online.
If you do intend to use an encrypted container and store backup copies of it online, then encrypt it again before storing it online. One approach would be to encrypt the container using a gpg key. Keep only the public key on your computer. Print out the private key along with the passphrase and store it in a safe.
It's almost not fair to mention KDE - almost. A major part of what makes KDE a nice environment is the window manager. With X11 systems you can use third party window managers. Windows on the other hand is not really designed for making the window manager replaceable. To make KDE run on Windows it will either require messing around with internals of Windows, or not port the entire thing. But what would be the point of porting KDE to Windows, if it wasn't going to give you the same feel to it. The most distinctive feature of KDE is the UI.
The first piece of free software that came to my mind was bash. Actually you can run bash on Windows through cygwin. I did try to use that professionally three years ago. But as soon as I started doing any nontrivial scripting, I realized that starting processes were orders of magnitudes slower than on Linux, and I just ssh'ed to a Linux machine to run my scripts there. (I was using cygwin to run xterm and ssh for that purpose. I liked that combination better than putty). I don't know if anybody tried to make a native Windows version of bash, but if anybody did, it would just never feel like the real thing.
I have an XP SP2 machine on which SP3 consistently fails to install. Thats the best reason that I've found so far.
No, that really isn't a good reason. It means something is severely broken with either the install or the upgrade, and most likely the problem is with the current install. If it had been a problem with the upgrade, it would have been reproducible and fixed. If your system is so broken it is impossible to install an upgrade, the best solution is not to refrain from upgrading it, but rather to find out what the heck is wrong and fix it. If you don't know what is causing the problem, how would you know what else it would break? If you can't figure out what is wrong, a reinstall is the way to go (even if it seems inconvenient).
A couple of years ago, the usual Linux ABI breakage - of which they are very proud of - made me unable to use Maple 8
The ABI changes in Linux only affects kernel internals. If an application needs its very own kernel modules to work, then I'd avoid that application. And the possibility that it might break when internal kernel ABI changes, is not the main reason I would want to avoid it.
So can I install just one system and choose between the two kernels at boot time? Or do you have to make a completely different install with executables build separately for each kernel?
The entire header must be digested in order to determine the route for the packet because the destination address is last.
Interesting. What is the rationale behind putting the source address before the destination address? I can certainly see the point in being able to start forwarding 20 bytes earlier, but would any routers do that anyway? In many situations a router should be checking the validity of the source address before forwarding, what would you do if you already started sending the packet and then realize the source address is invalid? You cannot truncate the packet if you are using ethernet frames because the length is before the payload, so you already send the length. You could of course end the frame with an invalid checksum. That leads to another challenge, what do you actually do about packets with invalid checksum? If you forward before receiving the entire packet, any corrupt packet will be forwarded all the way to the destination, and only at that point can the link layer checksum be verified. If you cut out enough forwarding latency, it becomes impossible to discard corrupted frames. The corruption is detected at the end of the packet, and no matter how you signal that the packet is corrupted, that signal won't catch up with the head of the packet. If the packet is 1500 bytes long, and you have 40 bytes of forwarding latency at each hop it takes 38 hops for an indication of a corrupted frame to catch up with the head of the frame. Routes with more than 30 hops are rare. It will also only work between interfaces running at exactly same bit rate. If you forward from a slow interface to a fast interface, you have to wait before you start sending, otherwise you will need to send the last byte of the packet before you receive it. From a fast to a slow link you can start sending as soon as you know which outgoing interface it will go to, but the slow link is more likely to be busy, so you have to buffer anyway. (If every hop along the way forwards as soon as possible, then inserting a 10Gbit/s link somewhere on a path of 1Gbit/s links will actually increase latency rather than decrease it). All of this makes me think you have to store and forward at least on some hops along the route.
Will a big Business really want to have all of there 1000's of pc to each have there own public ip address?
Yes, they will want that. That is of course assuming they understand the disadvantages of each solution.
Will people still us nat to get of having to pay for each IP?
I don't think so. First of all I don't think nearly as much effort has been put into implementing NAT for IPv6 as has been for IPv4. Besides, internet providers are supposed to give each customer several segments of 2^64 addresses each. Even if they only give you one segment, that is still more addresses than you have computers.
IPS like comcast will love to make you pay per pc like how then want to per tv with there digital cable outlet fees.
Not all providers are like that. There may be providers that want to screw you over and make you pay extra per computer. That's a fuzzy measure anyway, why not per CPU or per monitor? If it happens, you will find, that there will be other companies that will try to get a competitive advantage by giving you all the addresses you need. The reason that will happen is, that it will not cost them anything to give you that. On IPv4 it did have a cost to the provider to give you another address, with IPv6 it will have a cost to the provider to find a way not to give it to you.
In the end what really costs something is bandwidth and reliability. The competition on bandwidth have driven prices for bandwidth so low, that providers may sacrifice on reliability, try to find other ways to charge you, and even in that case not give you all the bandwidth you payed for. For some providers restricting the number of IP addresses is just another way to make money and make you use less of the bandwidth.
How stuff used on the Local network only that you works with ipv4?
take a look at 6lowpan, which allows you to statelessly compress headers down to under twelve bytes.
How would that work? There will always be at least one endpoint with an IPv6 address, which you have no control over. That is 16 bytes of potentially uncompressable data right there. What you could do is for the two units at the ends of the slow link to have some shared state with a list of the most frequently used IPv6 addresses. Maybe even a list of the most frequently used pairs of (IP,port), such that you just have to do one lookup in a table to decode it. That way you could compress 36 bytes of header data down to just 2 bytes in most cases. But you would need some way to update the state. You could reserve one of the 16 bit to indicate that you are sending a new sender and receiver pair, the two bytes would then be followed by the full 36 bytes. You'd have to keep sending the full sender and receiver addresses until the other end of the link has acknowledged that the table is updated on the other end. I have no idea if that is how 6lowpan works, but clearly to compress an IPv6 header to 12 bytes, you need some kind of state.
I don't know about native IPv6 support. But Apple Airport Extreme supports 6to4 out of the box, and is thought to account for half the machines currently on IPv6. According to Wikipedia there are a few more routers with 6to4 support. But they are a minority.
Isn't it the case with NAT that you're limited to a maximum of 65535 concurrent TCP or UDP connections?
No. You can do a lot more connections than that. First of all a TCP connection is identified by two endpoints. If you connect to two different remote addresses, the connections can actually come from the same local port number. That trick only works for TCP. For UDP there could be more than two parties involved, and such tricks would break. Also, you are not limited to a single external IP. An ISP could setup a separate NAT box for every n customers. But customers are going to get a worse internet experience, even if ISPs do spend more money on it. So before ISPs start doing such tricks, they will probably start offering IPv6 addresses in the hope that some users will no longer use IPv4 addresses. But I don't think many systems will refrain from requesting an IPv4 address over DHCP just because they were able to get an IPv6 address. However if ISPs do start deploying NAT boxes on a large scale, they'd better start offering native IPv6 at the same time, because that certainly can offload some of the connections from the NAT boxes. Even though a system may get both an IPv4 and IPv6 address, it isn't necessarily going to use them. Some systems will try IPv6 first, as long as the name resolves.
Translation and register renaming take up tiny amounts of die compared to the instruction cache savings of x86.
Only L1 cache actually make a distinction between instruction cache and data cache. And AFAIK the instruction cache actually stores the translated instructions, so there isn't going to be any savings from x86 code being more dense. But maybe you meant that the space you save for x86 instructions stored in L2 and L3 cache are worth more than the overhead of translation.
Anything of 16 bit real mode is so old that I doubt that there's still any patent on it. So there wouldn't be any problem in keeping that (this might be important in order to use existing BIOS, which usually is entirely 16 bit real mode). Just add the possibility to switch to 64 bit protected mode directly from 16 bit real mode, without going through 32 bit first.
Good point, that might actually be an easier path forward.
I think what could safely be removed in very short time is 16 bit protected mode (does anyone still use that?).
What exactly do you mean with that? The first protected mode Intel introduced was on the 286 and was a strange hybrid of 16 and 24 bits. With the 386 they introduced an extension of that, which allowed for 32 bit code. They extended the existing segment descriptors by using free bits in various places to support larger address space. The result was a bit messy, but completely backward compatible with 286 protected mode. In other words, the 386 only had one protected mode in which you could have some 16 bit segments and some 32 bit segments. With the 386 they also introduced paging. For a large part it was independent from the segmentation model. The result was, that you could run protected mode without making use of paging at all, but the other way around was not supported.
Also 16 bit virtual mode could probably go quite soon. With 32 bit mode, I don't think it could already be removed. Possibly in one or two years.
Do you mean virtual 86 mode could go? It doesn't exist in the 64 bit protected mode, only in the 32 bit protected mode. Notice that unlike the extension from 16 to 32 bit, the 64 bit was a completely new mode, that allowed them to throw away things they didn't like such as virtual 86 mode.
Removing support for all those old modes should also free die space for new stuff (extended precision sse maybe, then also the x87 stuff could finally be removed).
AFAIK they don't spend a lot of die space on older modes. I don't remember who told me this, but at some point I was told that the real mode is essentially implemented by just taking a very old and proven design and sticking in a small corner of the CPU. Since modern CPUs are made with much denser technology, it doesn't take up any significant die space, but it isn't optimized as much for performance as the newer modes that people use for everything important nowadays. Besides, most of the die space is actually used for L2/L3 caches, which are independent from the mode the CPU is operating in.
Since x86_64 is a superset of x86, would this mean AMD couldn't even sell x86_64 based chips either?
Is it time for AMD to make some more steps in throwing out the heritage from x86? Yes an x86-64 CPU can run in backward compatible 16 and 32 bit modes. In fact they still start up in 16 bit mode from which they have to be switched to 32 and then 64 bit mode. But the 64 bit mode could have done more to remain backwards compatible with old 16 and 32 bit code, however at the time AMD made the bold decision to allow some old software to not work in the 64 bit mode. Maybe it is time to take another step in getting rid of the heritage. How about making it possible for the CPUs to start up directly in 64 bit mode? That would be a natural next step towards completely getting rid of the backward compatible modes. The 64 bit instruction set can hardly be called the same instruction set as the 32 and 16 bit ones, first of all it is 64 bits, and it also has more general purpose registers. Those are clear distinctions from the old instruction set, and it was created by AMD, so I don't think Intel could prevent them from using it. I know you can run 16 and 32 bit code in the 64 bit mode, and a lot of people still use it (at least the 32 bit code), but I still think we are at the point where the 64 bit AMD ISA is more important than the 32 bit Intel ISA.
seccomp is almost exactly what I was thinking of, but written about 4 years ago.
Nice it is even enabled in Fedora kernels. I'll start using this whenever I can. It is less flexible than what I had in mind. I would have a bitmap of permitted system calls, from which you would only be allowed to remove calls. SECCOMP just have a list of four permitted calls. And I would have given an error code on attempts to access disallowed calls rather than just SIGKILL. It makes PR_GET_SECCOMP pretty pointless, because if you are in secure mode you are not permitted to call it anyway. I wonder why sigreturn is permitted, it is a fairly complicated call, that I could imagine could be used as an attack vector. Here is a bit of code for anybody who want to start playing around:
If you read the article, this is precisely false with ext4.
Well. The summary had multiple links, and the pages it pointed to had multiple links to other locations. And I haven't found out which one is supposed to explain exactly what happened.
A file is overwritten by being truncated to length zero and then new data is written.
A new file is created filled with data and renamed over an existing file
The first of those two is clearly a buggy application, and I'd rather the applications were fixed than the kernel have workarounds to minimize the risk of data loss. That case is one where data loss is to be expected, it could happen with any file system, the window for loss just happen to be larger on ext4.
The second case is one where a newly created file is renamed on top of an existing file. A pretty normal procedure. And I wrote "workaround" in quotes because the kernel isn't really working around something inherently wrong in the application. I'd rather say one part of ext4 is working around a problem in another part of it.
I have yet to find an authoritative source telling me which of the two "workarounds" apply to the KDE data loss. I did however find indications that a lot of other applications were affected as well. I can't imagine all of them have the bug of deleting the old version before creating the new one.
Or rather, the rename can be committed to disk before the data writes have been; if you crash in between, you lose.
I can understand that if the system crash and you didn't sync, then what you find on disk after rebooting may not be entirely up to date. If it matches something that logically was on disk two minutes before the crash, that would still be valid. I still think the system should try to minimize this window. In particular if the disk is idle, there is no reason why the difference should be more than one second.
However it sounds like what you get after reboot is something that didn't exist at any point in time. The name refers to a file of zero length after the reboot, and at no point in time did that name refer to an empty file, so it is not just an old version of some data, it is a corrupt version. Saying that it is conforming to the standard is a lame excuse, I'm pretty sure the standard does not say the system must cause data loss in this case.
It is possible to make a fix to the file system that handles this case without data loss and without performance hit. If the disk is idle and you don't want to allocate sectors for the data right away to get a better layout, then just commit the data to the journal. I don't know if the journal format already permits committing data for which no location has been allocated yet, but it certainly could be modified to support it. I doesn't cost you any performance to write the data twice in this case because the disk was already idle, and it doesn't give you a worse layout that will give you performance problems later, because the allocation of the final location is still delayed. If the system crashed before the delayed allocation had happened, it would then happen during journal replay. If the system is busy, it is acceptable for data to take a while to make it to disk, as long as data on disk is consistent. That means don't commit to the metadata changes until after the data which had to go before it has been committed to disk. Of course in that case you still have to take care to avoid starvation.
Saying that it should be fixed in the application is BS. Creating a new file and renaming that should be sufficie
Write new file into a temp file, sync, whatever you need to do. When you're done, delete original and rename the temp to the original's name.
That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.
The filesystem should be hitting the metal about 0.001 microseconds after I call write()
It most certainly should not. At that time the drive head will be located over some data that you do not want to be overwritten. Background writes exist for a reason. If applications have specific needs, they will have to sync the data themselves, otherwise it is up to the user. I don't think there is any good excuse for waiting multiple seconds before starting the writes if the disk is otherwise idle. But if the disk is busy, some delay is to be expected.
I agree that copyright should be made a fixed number of years after the release. The exact number of years can be discussed. I think 10 is not too bad. But I'd say it could vary depending on the kind of work with a minimum of 1 year and a maximum of 20. I don't see any reason why any copyright would need to be more than 20 years.
I also would like to see other restrictions in copyright. When releasing a work you should be forced to decide whether you want to protect it using copyright or technical means - not both. In other words, anything released under a DRM scheme is fair game for copying by anybody able to do so. That would be a much more reasonable law than the current system that allows works to be released under DRM schemes that prevents fair use (sometimes even prevents just watching a movie the way it was supposed to be watched) and even makes it illegal (in some countries) to do anything that the DRM system did not intend you to do. Why did lawmakers ever write such a blank cheque for the publishers?
Patents certainly have proven to be bad enough for some areas that they should just not be permitted. The way I'd reform the patent system would be to add more phases to the system in the following way. First you publicize the problem to be solved. Then society decides (details would have to be worked out) how much an invention to solve that problem would be worth. Then whoever first present an invention to solve the problem is granted the patent and can manufacture or sell licenses. The inventor gets pretty much free hands as today with a few exceptions. The total amount of money paid in licenses must be public, once it reaches the decided value the patent expires, and anybody who wants to can pay out the final amount to make the patent expire.
The point of that system would be to give a more fair compensation to inventors, and prevent patents on obvious ideas. I think there would need to be a designated period from publicizing the problem till decision on the value (for example six months), if the invention is presented during that period it is considered obvious and nobody is granted the patent.
Of course you could still work for several years before publicizing the problem you aim to solve, in order to get a head start, but you'd still be running two risks, maybe the invention would be valued very low by society, or maybe somebody else would come up with the solution very quickly. In both cases the time you spent would be a waste seen with the eyes of society, and the patent system should not encourage such waste.
There is nothing of value to Microsoft to buy back, so any money paid back would just be a waste. They could just accept that the end user went bankrupt and that they lost a bit of income. They haven't really lost anything in that case, just earned a bit less money than they expected to. If they had sold directly to the end user, there wouldn't be much money to collect anyway.
They might still have a right to get money from the middleman, but doing so could come with some bad press. They could request enough that the middleman goes bankrupt as well, and they may get what money is currently there. Otherwise they could accept that the middleman pay at a pace they can possibly do without going bankrupt. In the end the slow pace may give them more money.
An interesting question is whether the middleman could just sell those licenses to other companies now. Microsoft would probably say that is not allowed. I don't know if the court would find a contract valid if it requires payment for a license that is only allowed to be used by one company that is now bankrupt. If they actually are allowed to resell the licenses to other companies, that could flood the market with cheap licenses, probably something Microsoft does not want. The easy way to avoid that would be to accept that the contracts can be terminated without payment in this scenario. The other ways are to claim it is against the contract, or make the company go bankrupt with Microsoft being the only creditor with an interest in picking them up (and valuing them a lot less than they originally were paid for them).
Of course I'm no expert in Icelandic law, so this is all just guesswork. I wonder if Microsoft knows Icelandic law well enough to predict how this would turn out.
But I can't see this being good for Microsoft's sale of licenses in this way in the future, which should matter a lot more to them than what little money they can get from a few Icelandic companies.
Using IDE or SATA it is not possible in a "normal" setting, because there are 4 to 6 drives to the standard el cheapo IDE or SATA controller. With up to 7 or 8 slots on an E-ATX mainboard this is nowhere near 65 drives.
If you install 3 additional 4 port SATA controller cards and connect a five way SATA port multiplier to each port, you can connect more than 65 drives. The real problem is how to find a cabinet with another power and cooling for so many drives. Such a machine would probably be drawing close to 1kW from the grid.
Slashdot Mirror
Yes, that's just an example of what I said. 2, 3, 5, or 7 digits will give you prime numbers 3, 7, 31, and 127. But with 11 digits you get 2047 which is not a prime number.
Obviously the number of digits would have to be a prime number. But not all prime number of digits would give you a prime number. The first case is when there are 11 digits, the number would be 23*89 in that case.
That is just a case of a cure that is worse than the disease. It is pieces of javascript like that which is the reason why browsers allow you to disable javascript. Consider for example the case where you search for something in Google Images. When you click on an image, it takes you to a page from where you can either follow a link to the image or to the page it was found on. It also has a frame that serves as a preview of the page. Overall I like that UI, but the webpage inside that frame can break the UI by using javascript like you suggest. I see it happening all the time, and usually it takes you to a page that doesn't even contain the image you searched for. If you disable javascript, you won't have that kind of bad experience. But the main search results page in Google Images also uses javascript to format the results better for the size of your window. If you disable javascript Google Images doesn't render as nicely.
I know there exist browser extensions, that will allow the user to disable javascript on a per site basis. But I really don't think that is a good solution. First of all the existence of an extension is a lame excuse for not doing something sensible by default. Secondly I don't want to make such decisions on a per site basis. With javascript enabled for just some sites, you basically have to keep it off by default and just enable it for a few trusted sites. But you will get a worse experience because there are so many sites, that makes good use of javascript to make the page work just a little better.
What browsers should do is not to put restrictions on which sites can use javascript, but on what they can do with it. Letting a frame mess with the parent should not be permitted by default. But since in some rare cases it can be used in a good way, it should still be possible with cooperation from the parent frame.
Wait. Are you telling me those emails I received from FBI with an attached program I had to run were actually real?
Before anybody starts using TrueCrypt for encrypting data to be stored online, let me warn you, that TrueCrypt was not designed for that. Several years ago TrueCrypt switched to LRW because the encryption mode used before that was vulnerable to some watermarking attacks. However the LRW encryption was even more vulnerable in case an adversary is able to get a copy of the encrypted data from two different points in time. What that means is, that if you just have the encrypted container stored online using some networking file system, then whoever operates the server will have access to the encrypted data from any point in time. By comparing the data from different points in time, you can perform watermarking attacks. The same applies if you store your encrypted container locally but periodically put a backup of it on a server not directly controlled by you.
I mentioned above vulnerability to the TrueCrypt authors, but they didn't consider it a problem. However I think they did switch to a different mode later for other (less severe) reasons. I don't know if the new mode is better, but I doubt it. I have not yet seen any storage encryption specifically designed to handle this use case. Anything I have seen operating at the block layer TrueCrypt, cryptoloop, GBDE, etc. have been designed without considering the possibility that an adversary would have access to the encrypted data from two different points in time, in other words they are not suitable for storing online.
If you do intend to use an encrypted container and store backup copies of it online, then encrypt it again before storing it online. One approach would be to encrypt the container using a gpg key. Keep only the public key on your computer. Print out the private key along with the passphrase and store it in a safe.
Sucks when you find out that the hackers were trying to perform a denial of service attack against your system.
It's almost not fair to mention KDE - almost. A major part of what makes KDE a nice environment is the window manager. With X11 systems you can use third party window managers. Windows on the other hand is not really designed for making the window manager replaceable. To make KDE run on Windows it will either require messing around with internals of Windows, or not port the entire thing. But what would be the point of porting KDE to Windows, if it wasn't going to give you the same feel to it. The most distinctive feature of KDE is the UI.
The first piece of free software that came to my mind was bash. Actually you can run bash on Windows through cygwin. I did try to use that professionally three years ago. But as soon as I started doing any nontrivial scripting, I realized that starting processes were orders of magnitudes slower than on Linux, and I just ssh'ed to a Linux machine to run my scripts there. (I was using cygwin to run xterm and ssh for that purpose. I liked that combination better than putty). I don't know if anybody tried to make a native Windows version of bash, but if anybody did, it would just never feel like the real thing.
No, that really isn't a good reason. It means something is severely broken with either the install or the upgrade, and most likely the problem is with the current install. If it had been a problem with the upgrade, it would have been reproducible and fixed. If your system is so broken it is impossible to install an upgrade, the best solution is not to refrain from upgrading it, but rather to find out what the heck is wrong and fix it. If you don't know what is causing the problem, how would you know what else it would break? If you can't figure out what is wrong, a reinstall is the way to go (even if it seems inconvenient).
The ABI changes in Linux only affects kernel internals. If an application needs its very own kernel modules to work, then I'd avoid that application. And the possibility that it might break when internal kernel ABI changes, is not the main reason I would want to avoid it.
So can I install just one system and choose between the two kernels at boot time? Or do you have to make a completely different install with executables build separately for each kernel?
Interesting. What is the rationale behind putting the source address before the destination address? I can certainly see the point in being able to start forwarding 20 bytes earlier, but would any routers do that anyway? In many situations a router should be checking the validity of the source address before forwarding, what would you do if you already started sending the packet and then realize the source address is invalid? You cannot truncate the packet if you are using ethernet frames because the length is before the payload, so you already send the length. You could of course end the frame with an invalid checksum. That leads to another challenge, what do you actually do about packets with invalid checksum? If you forward before receiving the entire packet, any corrupt packet will be forwarded all the way to the destination, and only at that point can the link layer checksum be verified. If you cut out enough forwarding latency, it becomes impossible to discard corrupted frames. The corruption is detected at the end of the packet, and no matter how you signal that the packet is corrupted, that signal won't catch up with the head of the packet. If the packet is 1500 bytes long, and you have 40 bytes of forwarding latency at each hop it takes 38 hops for an indication of a corrupted frame to catch up with the head of the frame. Routes with more than 30 hops are rare. It will also only work between interfaces running at exactly same bit rate. If you forward from a slow interface to a fast interface, you have to wait before you start sending, otherwise you will need to send the last byte of the packet before you receive it. From a fast to a slow link you can start sending as soon as you know which outgoing interface it will go to, but the slow link is more likely to be busy, so you have to buffer anyway. (If every hop along the way forwards as soon as possible, then inserting a 10Gbit/s link somewhere on a path of 1Gbit/s links will actually increase latency rather than decrease it). All of this makes me think you have to store and forward at least on some hops along the route.
Yes, they will want that. That is of course assuming they understand the disadvantages of each solution.
I don't think so. First of all I don't think nearly as much effort has been put into implementing NAT for IPv6 as has been for IPv4. Besides, internet providers are supposed to give each customer several segments of 2^64 addresses each. Even if they only give you one segment, that is still more addresses than you have computers.
Not all providers are like that. There may be providers that want to screw you over and make you pay extra per computer. That's a fuzzy measure anyway, why not per CPU or per monitor? If it happens, you will find, that there will be other companies that will try to get a competitive advantage by giving you all the addresses you need. The reason that will happen is, that it will not cost them anything to give you that. On IPv4 it did have a cost to the provider to give you another address, with IPv6 it will have a cost to the provider to find a way not to give it to you.
In the end what really costs something is bandwidth and reliability. The competition on bandwidth have driven prices for bandwidth so low, that providers may sacrifice on reliability, try to find other ways to charge you, and even in that case not give you all the bandwidth you payed for. For some providers restricting the number of IP addresses is just another way to make money and make you use less of the bandwidth.
I have no idea what you are talking about.
How would that work? There will always be at least one endpoint with an IPv6 address, which you have no control over. That is 16 bytes of potentially uncompressable data right there. What you could do is for the two units at the ends of the slow link to have some shared state with a list of the most frequently used IPv6 addresses. Maybe even a list of the most frequently used pairs of (IP,port), such that you just have to do one lookup in a table to decode it. That way you could compress 36 bytes of header data down to just 2 bytes in most cases. But you would need some way to update the state. You could reserve one of the 16 bit to indicate that you are sending a new sender and receiver pair, the two bytes would then be followed by the full 36 bytes. You'd have to keep sending the full sender and receiver addresses until the other end of the link has acknowledged that the table is updated on the other end. I have no idea if that is how 6lowpan works, but clearly to compress an IPv6 header to 12 bytes, you need some kind of state.
I don't know about native IPv6 support. But Apple Airport Extreme supports 6to4 out of the box, and is thought to account for half the machines currently on IPv6. According to Wikipedia there are a few more routers with 6to4 support. But they are a minority.
No. You can do a lot more connections than that. First of all a TCP connection is identified by two endpoints. If you connect to two different remote addresses, the connections can actually come from the same local port number. That trick only works for TCP. For UDP there could be more than two parties involved, and such tricks would break. Also, you are not limited to a single external IP. An ISP could setup a separate NAT box for every n customers. But customers are going to get a worse internet experience, even if ISPs do spend more money on it. So before ISPs start doing such tricks, they will probably start offering IPv6 addresses in the hope that some users will no longer use IPv4 addresses. But I don't think many systems will refrain from requesting an IPv4 address over DHCP just because they were able to get an IPv6 address. However if ISPs do start deploying NAT boxes on a large scale, they'd better start offering native IPv6 at the same time, because that certainly can offload some of the connections from the NAT boxes. Even though a system may get both an IPv4 and IPv6 address, it isn't necessarily going to use them. Some systems will try IPv6 first, as long as the name resolves.
Only L1 cache actually make a distinction between instruction cache and data cache. And AFAIK the instruction cache actually stores the translated instructions, so there isn't going to be any savings from x86 code being more dense. But maybe you meant that the space you save for x86 instructions stored in L2 and L3 cache are worth more than the overhead of translation.
Good point, that might actually be an easier path forward.
What exactly do you mean with that? The first protected mode Intel introduced was on the 286 and was a strange hybrid of 16 and 24 bits. With the 386 they introduced an extension of that, which allowed for 32 bit code. They extended the existing segment descriptors by using free bits in various places to support larger address space. The result was a bit messy, but completely backward compatible with 286 protected mode. In other words, the 386 only had one protected mode in which you could have some 16 bit segments and some 32 bit segments. With the 386 they also introduced paging. For a large part it was independent from the segmentation model. The result was, that you could run protected mode without making use of paging at all, but the other way around was not supported.
Do you mean virtual 86 mode could go? It doesn't exist in the 64 bit protected mode, only in the 32 bit protected mode. Notice that unlike the extension from 16 to 32 bit, the 64 bit was a completely new mode, that allowed them to throw away things they didn't like such as virtual 86 mode.
AFAIK they don't spend a lot of die space on older modes. I don't remember who told me this, but at some point I was told that the real mode is essentially implemented by just taking a very old and proven design and sticking in a small corner of the CPU. Since modern CPUs are made with much denser technology, it doesn't take up any significant die space, but it isn't optimized as much for performance as the newer modes that people use for everything important nowadays. Besides, most of the die space is actually used for L2/L3 caches, which are independent from the mode the CPU is operating in.
Is it time for AMD to make some more steps in throwing out the heritage from x86? Yes an x86-64 CPU can run in backward compatible 16 and 32 bit modes. In fact they still start up in 16 bit mode from which they have to be switched to 32 and then 64 bit mode. But the 64 bit mode could have done more to remain backwards compatible with old 16 and 32 bit code, however at the time AMD made the bold decision to allow some old software to not work in the 64 bit mode. Maybe it is time to take another step in getting rid of the heritage. How about making it possible for the CPUs to start up directly in 64 bit mode? That would be a natural next step towards completely getting rid of the backward compatible modes. The 64 bit instruction set can hardly be called the same instruction set as the 32 and 16 bit ones, first of all it is 64 bits, and it also has more general purpose registers. Those are clear distinctions from the old instruction set, and it was created by AMD, so I don't think Intel could prevent them from using it. I know you can run 16 and 32 bit code in the 64 bit mode, and a lot of people still use it (at least the 32 bit code), but I still think we are at the point where the 64 bit AMD ISA is more important than the 32 bit Intel ISA.
Nice it is even enabled in Fedora kernels. I'll start using this whenever I can. It is less flexible than what I had in mind. I would have a bitmap of permitted system calls, from which you would only be allowed to remove calls. SECCOMP just have a list of four permitted calls. And I would have given an error code on attempts to access disallowed calls rather than just SIGKILL. It makes PR_GET_SECCOMP pretty pointless, because if you are in secure mode you are not permitted to call it anyway. I wonder why sigreturn is permitted, it is a fairly complicated call, that I could imagine could be used as an attack vector. Here is a bit of code for anybody who want to start playing around:
Well. The summary had multiple links, and the pages it pointed to had multiple links to other locations. And I haven't found out which one is supposed to explain exactly what happened.
I went to read https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 again, and though the wording there is quite confusing, by reading it again now a bit earlier in the day, I managed to figure out that it describes "workarounds" for two situations.
The first of those two is clearly a buggy application, and I'd rather the applications were fixed than the kernel have workarounds to minimize the risk of data loss. That case is one where data loss is to be expected, it could happen with any file system, the window for loss just happen to be larger on ext4.
The second case is one where a newly created file is renamed on top of an existing file. A pretty normal procedure. And I wrote "workaround" in quotes because the kernel isn't really working around something inherently wrong in the application. I'd rather say one part of ext4 is working around a problem in another part of it.
I have yet to find an authoritative source telling me which of the two "workarounds" apply to the KDE data loss. I did however find indications that a lot of other applications were affected as well. I can't imagine all of them have the bug of deleting the old version before creating the new one.
I can understand that if the system crash and you didn't sync, then what you find on disk after rebooting may not be entirely up to date. If it matches something that logically was on disk two minutes before the crash, that would still be valid. I still think the system should try to minimize this window. In particular if the disk is idle, there is no reason why the difference should be more than one second.
However it sounds like what you get after reboot is something that didn't exist at any point in time. The name refers to a file of zero length after the reboot, and at no point in time did that name refer to an empty file, so it is not just an old version of some data, it is a corrupt version. Saying that it is conforming to the standard is a lame excuse, I'm pretty sure the standard does not say the system must cause data loss in this case.
It is possible to make a fix to the file system that handles this case without data loss and without performance hit. If the disk is idle and you don't want to allocate sectors for the data right away to get a better layout, then just commit the data to the journal. I don't know if the journal format already permits committing data for which no location has been allocated yet, but it certainly could be modified to support it. I doesn't cost you any performance to write the data twice in this case because the disk was already idle, and it doesn't give you a worse layout that will give you performance problems later, because the allocation of the final location is still delayed. If the system crashed before the delayed allocation had happened, it would then happen during journal replay. If the system is busy, it is acceptable for data to take a while to make it to disk, as long as data on disk is consistent. That means don't commit to the metadata changes until after the data which had to go before it has been committed to disk. Of course in that case you still have to take care to avoid starvation.
Saying that it should be fixed in the application is BS. Creating a new file and renaming that should be sufficie
That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.
It most certainly should not. At that time the drive head will be located over some data that you do not want to be overwritten. Background writes exist for a reason. If applications have specific needs, they will have to sync the data themselves, otherwise it is up to the user. I don't think there is any good excuse for waiting multiple seconds before starting the writes if the disk is otherwise idle. But if the disk is busy, some delay is to be expected.
I agree that copyright should be made a fixed number of years after the release. The exact number of years can be discussed. I think 10 is not too bad. But I'd say it could vary depending on the kind of work with a minimum of 1 year and a maximum of 20. I don't see any reason why any copyright would need to be more than 20 years.
I also would like to see other restrictions in copyright. When releasing a work you should be forced to decide whether you want to protect it using copyright or technical means - not both. In other words, anything released under a DRM scheme is fair game for copying by anybody able to do so. That would be a much more reasonable law than the current system that allows works to be released under DRM schemes that prevents fair use (sometimes even prevents just watching a movie the way it was supposed to be watched) and even makes it illegal (in some countries) to do anything that the DRM system did not intend you to do. Why did lawmakers ever write such a blank cheque for the publishers?
Patents certainly have proven to be bad enough for some areas that they should just not be permitted. The way I'd reform the patent system would be to add more phases to the system in the following way. First you publicize the problem to be solved. Then society decides (details would have to be worked out) how much an invention to solve that problem would be worth. Then whoever first present an invention to solve the problem is granted the patent and can manufacture or sell licenses. The inventor gets pretty much free hands as today with a few exceptions. The total amount of money paid in licenses must be public, once it reaches the decided value the patent expires, and anybody who wants to can pay out the final amount to make the patent expire.
The point of that system would be to give a more fair compensation to inventors, and prevent patents on obvious ideas. I think there would need to be a designated period from publicizing the problem till decision on the value (for example six months), if the invention is presented during that period it is considered obvious and nobody is granted the patent.
Of course you could still work for several years before publicizing the problem you aim to solve, in order to get a head start, but you'd still be running two risks, maybe the invention would be valued very low by society, or maybe somebody else would come up with the solution very quickly. In both cases the time you spent would be a waste seen with the eyes of society, and the patent system should not encourage such waste.
There is nothing of value to Microsoft to buy back, so any money paid back would just be a waste. They could just accept that the end user went bankrupt and that they lost a bit of income. They haven't really lost anything in that case, just earned a bit less money than they expected to. If they had sold directly to the end user, there wouldn't be much money to collect anyway.
They might still have a right to get money from the middleman, but doing so could come with some bad press. They could request enough that the middleman goes bankrupt as well, and they may get what money is currently there. Otherwise they could accept that the middleman pay at a pace they can possibly do without going bankrupt. In the end the slow pace may give them more money.
An interesting question is whether the middleman could just sell those licenses to other companies now. Microsoft would probably say that is not allowed. I don't know if the court would find a contract valid if it requires payment for a license that is only allowed to be used by one company that is now bankrupt. If they actually are allowed to resell the licenses to other companies, that could flood the market with cheap licenses, probably something Microsoft does not want. The easy way to avoid that would be to accept that the contracts can be terminated without payment in this scenario. The other ways are to claim it is against the contract, or make the company go bankrupt with Microsoft being the only creditor with an interest in picking them up (and valuing them a lot less than they originally were paid for them).
Of course I'm no expert in Icelandic law, so this is all just guesswork. I wonder if Microsoft knows Icelandic law well enough to predict how this would turn out.
But I can't see this being good for Microsoft's sale of licenses in this way in the future, which should matter a lot more to them than what little money they can get from a few Icelandic companies.
If you install 3 additional 4 port SATA controller cards and connect a five way SATA port multiplier to each port, you can connect more than 65 drives. The real problem is how to find a cabinet with another power and cooling for so many drives. Such a machine would probably be drawing close to 1kW from the grid.