Didn't you even read TF summary. They did an automated check of historical trends. It says nothing about getting the errors fixed and I expect most of the ones they've found were fixed a long time ago. Even the most recent sample is likely to be fairly old and so the mistakes will tend to have been fixed and all new ones inserted.
As for an automated fix, we've all seen the spellchecker horror stories sites.
I did use forth for a little while a long time ago. But I'm far to comfortable with normal algebraic notation to stay with it.
So, IMO it's no use as a high level language, but it makes a very good assembly language especially if you're space constrained because optimising for space is just a simple LZW style compression algorithm. Something that is very, very well understood.
So it'll never die, just get hidden everywhere there's half a penny to be shaved.
No it doesn't. It does break PPTP and IPSEC because the people who created those standards never believed people would be stupid enough to use something as dumb as NAT in the real world. But the more recent OpenVPN and some of the it's copycats (eg IPSEC variants) will always work with NAT at one end and can work the NAT at both ends; if you're using a high performance NAT, eg a linux router or a "CGN".
3. Forces users that need a public facing IP... to pay
I don't mind the paying so much, but I'll make REAL SURE I don't pay my ISP for the connectivity "extras". Use a third party preferably using OpenVPN (because it's rather hard to identify on the wire) and preferably in another country.
2. Double-NAT inherently breaks... bit torrent,
Yup, breaks the most efficient file transfer protocol invented so instead the people have to use a VPN or streamed video. (assuming we're assuming the MPAA assumption that all bit torrent is video) Streamed video is the worst; it has to be delivered on time and at the rate required, no slip-ups, no slow-down, no delays. And they hope this will mean their network can be cheaper for the same level of complaints... fat chance.
So if you use this metric for anything important to the employee the end of the day becomes either "chatting with Doris" or fast ugly 'fixes', to get the numbers to match the 'right' value.
Are you sure about that, remember we're talking about native code not DotNet. While DotNet does appear to have distinct 32bit and 64bit compilers the native C++ compiler appears to be only available as a 32bit executable that cross compiles to x64 or ia64 (and probably still 16bit too).
there's speed to be won
It used to be that you could write an algorithm in C get the compiler to generate the code and then improve the code by hand.
It's more the case nowadays that if you want or need to do that you should really be making sure that you are using the right compiler. Specifically, the Intel C compiler will generally be able to use all the instructions of the (Intel) CPU you point it at and will end up costing less (time, money or whatever) than doing the job by hand.
And even if you have to use a compiler that doesn't understand your special hardware accelerated instruction the inline assembler is normally more than good enough to specify the rules for using it and optimising around it without the compiler knowing exactly what it does.
Of course there is the other problem; the main reason I stopped hand optimising is that there isn't a single x86 CPU, methods of speeding up one variant will slow down others, but never by much because it's rare that the CPU is the bottleneck anymore. It's far more likely to be the memory and IME you can more easily help the compiler optimise memory accesses by working on the original C/++ code. Doing (or with c99 'allowing') optimisations the compiler won't because it can't make assumptions that you think are obvious.
That BTW is what PGO does, it allows the compiler to go and check on assumptions it's not allowed to make, it can check aggressive aliasing rules or simplify function calling (or eliminate it by inlining between modules) or even making subroutines (not functions) for rarely used code. It's not a new optimisation method, just bigger.
NO program needs 4GB of code space you'd need of the order of 200 million lines of code in a single executable to get anywhere near it, so with that amount of address space available overlays are unnecessary.
Also very few programs need more that 4GB of data space. Before today I knew of only two Microsoft applications that would benefit from more that 2GB of data space; MS-SQL and MS-Exchange.
Now it appears that that MS C++ compiler & linker could (very) occasionally benefit from a 64bit implementation... but Microsoft aren't making a 64bit version of VS so it must be really rare as they're pushing hard for 64bit only.
As for assembly, it was quite a while ago now that C/C++ compliers became better assembly code generators than people. For a modern heavily optimising complier hand written assembler will usually perform worse than the code emitted by the compiler. Not least because of features like the "PGO" that's causing the problem for Firefox where the compiler is trying to find optimisations over the entire executable, not just for small regions of code.
we're not allowed to create special users or change the OS configuration
You're pretty much screwed as far as that OS is concerned. If you're really lucky there might be a copy of KDE installed with it's kiosk mode, or perhaps you can kill enough of the window manager to get it stuck (but that's supposed to result in the window manager restarting itself).
If you can't change the disk you're only option is to replace it. I don't mean physically, though that may be an option, I mean with live CD, usb or netboot
The Debian Live project allows you to easily create a live CD (or the other media) with your choice of packages; so easily in fact that there used to be an automatic service for it, upload the package list, download the ISO.
So install a minimal Debian with ONLY the bits you need turn it into a live image and boot it off the network.
This Drive is CRAP
ASSUMING that it still only does read caching.
I bought one of the Gen-1 drives and was very underwhelmed. I wanted write caching; 4GB of non-volatile memory with the performance of SLC flash could allow windows (or whatever) to write to the drive flat out for up many seconds without a single choke due to the drive.
In addition 4G of write-back cache is enough to give a significant performance boost for continuous random writes across the drive and even more so across a small extent such as a database or a DotNET native image cache.
But for reading it's insignificant compared to the 3-16Gbytes of (so much faster) main memory that most systems contain, except at boot time when, unlike RAM, it will already contain some data. The problem with this is that it will contain the most recently read data, whereas the boot files can quite reasonably be described as least recently read.
So in the real world it's useless for anything except a machine that's rebooted every five minutes...
If you tell Ubuntu to stop nagging it will, it'll either install everything or nothing, whichever you decide.
Windows on the other hand don't stop. If you tell it to install everything it still nags about some normal updates and updates to lawyereese and demands a reboot every time. If you tell it to just stop nagging it'll nag you that it's not allowed to nag if you disable that second nag there's yet another one. Then even if you get Windows itself to "shut up!!!" many so called anti-virus programs will start nagging and they don't stop till they're uninstalled. They you find something doesn't work because it needs one of the services you've disabled to stop the nagging...
Basically their support is abominable and the >= 20Mb services are a lie.
Firstly the upstream is less than 10% of the downstream so the only way you can hope to fill the downstream is to 'tune' your IP stack to reduce the size of the ACK packets your stack replies with. Even then it's not likely.
Secondly they have a vicious 'peak time' data transfer limit that cripples your connection speed if you download something large, or watch a higher quality stream, in the later afternoon or evening.
And thirdly their router capacity is completely overloaded; most of the time you downloads are limited to around 500kbit/s per TCP channel due to the overloaded links on their network. For example, on another ISP I was able to download from Microsoft at over 10Mbit/s, but to get anywhere near Virgin's advertised 20Mbit/s I had to open 40 TCP connections.
So here I am at home with a reasonable 14Mbit/s ADSL and the ISP seems to have the uplinks to support it... But I am changing soon, BSkyB have poor support and will only let you replace their shitty modems if you have the technical ability to browbeat them into submission. (ie: 45 minutes on the phone shooting down every suggestion and, politely, calling them morons.)
At work I did look into the fibre to the box option, what worried me most was the reliability question. The price was high, but it may have been worthwhile if it weren't on the bleeping edge. So in the end I got an Annex-M (2Mbit upstream) ADSL line from 'Be' (now part of O2). The support is good and they let you adjust the configuration of the line so you can choose what speed/reliability tradeoff you want. As we're literally a stones throw from the exchange (with a small catapult) I've turned everything "up to 11" and it's still fast and stable with a 13ms ping to google.
I doubt it. There was a story yesterday that 60% of malware found in the wild has no AV-software coverage.
Why should that be a surprise? AV software is installed on every vulnerable PC sold and even without updates it mostly protects against all the old threats. Even after that there is a pretty good chance it's infernal nagging for a credit card will get an updated AV installed, with or without a CC. The "mindshare" has been built, everybody believes that Windows must have anti-virus.
But, as has been said repeatedly the AV industry is reactive (though they are starting to try to solve the HARD problem of being intelligently proactive) so all an attacker has to do is make sure that the initial infection vector is obscure. If the initial infection disables the AV it can then download anything; including corpses of old viruses to blame and new updates to run with. The result is that the initial infecting agent will probably no longer exist on the machine, either the botnet will have been upgraded to the most recent version, which isn't yet on the the AV list, or the initial infector will be hidden away to try and stop it getting on the lists at all.
When I consider it, if I was in "the business", I'd be trying pretty hard to keep information out of the hands of the AV "white hats" and it wouldn't really be difficult, I'd just have to keep changing things to keep one step ahead.
U238 can be burnt in a reactor. Using reasonable growth models the U238 present on the Earth with last longer than it will take solar radiation to make the Earth uninhabitable.
It also won't require that most of the world's desert gets covered in solar cells.
Flash memory cannot be 'quick formatted' each block has to be properly erased before use because writing can only turn 1's into 0's. (Obviously, the filesystem on a flash device can be quick formatted; but a recent OS will tell the flash about this, using the "TRIM" command, and the flash will erase all the blocks anyway.)
Some flash drives even understand the NTFS filesystem well enough to erase unallocated blocks without help; but that seems a little dangerous to me.
BTW: What Kubiatowicz seems to be saying is that pulling electrons from the substrate into the gates of a flash drive makes it heavier. So erasing the blocks, ie shorting them to ground, makes them lighter. So while downloading a book could make the device lighter, erasing the device will make it lighter still.
1. OSS evangelist throws sales pitch at newbie
2. Newbie starts using OSS, tries to file a bug
3. "Scratch my own itch" developer tells him to get lost
That's easy; the "Newbie" didn't do his "caveat emptor".
Exactly the same things apply no matter how much you pay for a copy of software. If you were buying the physical medium (or paying the cost of a server) the price would be tiny or covered by the adverts (or something). What you're paying for is a bribe so the author will come back and do something to fix your problems or make something even better. With free software the author has stated they're not particularly interested in getting cash (or don't expect to get enough for it to be worthwhile) so you need another way of getting their attention.
Sometimes flattery works; but they tend to be pretty good at spotting saccharin. Of course a newbie bug report often starts off: "This software is crap!", this is not a good start. Other times nothing can work, because just a "bug report" is never enough, the developer has to be able to reproduce the problem. I expect this is the issue for the Linux kernel developers in respect of the virtualbox module. They never use the module, they use physical machines or kvm (and used to use vmware).
One last thing; don't let this put you off from sending bug reports, it may be that just the information you can send is enough for this bug, this gets much more likely if you can send an effective bug report.
Except when the web traffic is "P2P" of course; like it is whenever they say it is.
All net traffic is between two peers, this is a legal (and journo's) distinction without any real world (eg: technical) meaning. The closest you can get to what they really mean is probably that a company is paying for the machine you're connecting to not an individual.
So you couldn't possibly encode that in a filter which means you have to show 'best efforts', get some piece of software that promises to do the impossible and you're in a good position to defend when that accusation comes along.
Only if you use an extra pointer to point at the bytes of the string (so you can manufacture a string header anywhere at run time) or you copy your byte array to somewhere where there is some clear space before the string so that the library functions can find the length value where they expect it.
If you don't you'd have to have a complete set of special functions to use the different format constant strings or a special function call to convert the byte array plus length into a proper "string" structure.
In the end you'd waste more space dealing with the difference than you would just adding the fake string header in the first place.
He's underestimated the space cost. It's not just lose the NUL
byte and gain an integer length, just encoding the current length in the
type doesn't protect you from buffer overflows. For that you also need
a maxstrlen integer.
So the size would be a length int, a maxlen int and the bytes of the
string. But you're lucky, you see malloc holds a integer too for the
length of the memory block it will free back into the pool, this can
be overloaded with the maxstrlen field. So you're back to two bytes of
overhead for a malloc'd string.
Constant strings are another matter, they don't have the malloc header
so something else would have to be done. Probably the easiest would be
to set the malloc length to zero, it's a constant after all so doesn't
need to be freed or overwritten. That does mean 4.5 bytes overhead
(including alignment) though.
The problem comes with buffers on the stack. These have a fixed chunk of
memory allocated and so can't be expanded. But the malloc header we have
for the strings explicitly can be expanded. There are two solutions; we
could spend two more bytes and add a pointer to the base string structure
then malloc the bytes for the string itself independently. A malloc'd
string would be malloc's in two pieces doubling the malloc overhead and
we'd have to do something about freeing this malloc'd space when the
buffer goes out of scope... I'm stuck, this isn't C anymore.
So the second choice goes right back to the start, the malloc size
(maxstrlen) is now a hard limit; no library routine can expand it after
it's been created. A string on the stack has a fake malloc header and
the current string length (overheader 4.5 bytes). Of course there's
the problem as to what to do if the string is too big; there are no
exceptions, just truncation. (more, different, bugs)
So that's it the additional overhead is three bytes, not one, plus the
alignment overhead. Two of the bytes (and the alignment) disappear with
malloc'd strings but the added complexity stays.
This runs upto 20Mb/s; shared; less for long range. It's not for you.
If you want to give your subscribers 8Mb/s down and 0.8Mb/s upload at say 50:1 contention ratio that's "20000000 *50 / (1.1 * 8000000)", my calculator says 113 users, over a 62 mile radius.
It can handle 25 uploading at full speed (no problem) but only TWO downloading at full speed. BIG problem; you'd have to make sure you have a good router at the head that can share the bandwidth between customers not just TCP sessions. On a variable bandwidth connection too... interesting times.
This bandwidth seems to be per former TV channel so you'll be able to multiply this up by however many TV channels you can use; as I recall that was only five or six within a given area because of interference from other transmitters. But it's better "out in the sticks".
So it looks like it's okay for getting some sort of internet connection to a house ten miles down a dirt track; but not much else at the ISP level.
As for mesh networking. One of the problems with broadcast is chattering network adaptors. One of the design criteria for this seem to be to maximise peak node to node bandwidth available. This means that a single chattering node will take out a substantial percentage of the available bandwidth perhaps all of it. As someone who has had to hunt down such an ethernet card back in the bad old days I truly pity anyone tasked with this job over a 12000sqmile area.
And I think you're wrong, there's no "rm" involved.
The removal is that the file details are being cleared from the memory cache and the cp is only looking in the cache for something it knew was there but hasn't locked yet. Because it wasn't locked another thread though it was a good candidate to be removed from the cache. The cp then assumed it was gone because something physically deleted it.
I know, I'm not very good at propaganda. But like the best propaganda everything I said is true, however, I've tried to be 'complete', ie not take anything out of context.
Slashdot Mirror
Didn't you even read TF summary. They did an automated check of historical trends. It says nothing about getting the errors fixed and I expect most of the ones they've found were fixed a long time ago. Even the most recent sample is likely to be fairly old and so the mistakes will tend to have been fixed and all new ones inserted.
As for an automated fix, we've all seen the spellchecker horror stories sites.
I did use forth for a little while a long time ago. But I'm far to comfortable with normal algebraic notation to stay with it.
So, IMO it's no use as a high level language, but it makes a very good assembly language especially if you're space constrained because optimising for space is just a simple LZW style compression algorithm. Something that is very, very well understood.
So it'll never die, just get hidden everywhere there's half a penny to be shaved.
2. Double-NAT inherently breaks ... VPN connectivity.
No it doesn't. It does break PPTP and IPSEC because the people who created those standards never believed people would be stupid enough to use something as dumb as NAT in the real world. But the more recent OpenVPN and some of the it's copycats (eg IPSEC variants) will always work with NAT at one end and can work the NAT at both ends; if you're using a high performance NAT, eg a linux router or a "CGN".
3. Forces users that need a public facing IP ... to pay
I don't mind the paying so much, but I'll make REAL SURE I don't pay my ISP for the connectivity "extras". Use a third party preferably using OpenVPN (because it's rather hard to identify on the wire) and preferably in another country.
2. Double-NAT inherently breaks ... bit torrent,
Yup, breaks the most efficient file transfer protocol invented so instead the people have to use a VPN or streamed video. (assuming we're assuming the MPAA assumption that all bit torrent is video) Streamed video is the worst; it has to be delivered on time and at the rate required, no slip-ups, no slow-down, no delays. And they hope this will mean their network can be cheaper for the same level of complaints ... fat chance.
So if you use this metric for anything important to the employee the end of the day becomes either "chatting with Doris" or fast ugly 'fixes', to get the numbers to match the 'right' value.
Next ...
32bit and 64bit toolchains
Are you sure about that, remember we're talking about native code not DotNet. While DotNet does appear to have distinct 32bit and 64bit compilers the native C++ compiler appears to be only available as a 32bit executable that cross compiles to x64 or ia64 (and probably still 16bit too).
there's speed to be won
It used to be that you could write an algorithm in C get the compiler to generate the code and then improve the code by hand.
It's more the case nowadays that if you want or need to do that you should really be making sure that you are using the right compiler. Specifically, the Intel C compiler will generally be able to use all the instructions of the (Intel) CPU you point it at and will end up costing less (time, money or whatever) than doing the job by hand.
And even if you have to use a compiler that doesn't understand your special hardware accelerated instruction the inline assembler is normally more than good enough to specify the rules for using it and optimising around it without the compiler knowing exactly what it does.
Of course there is the other problem; the main reason I stopped hand optimising is that there isn't a single x86 CPU, methods of speeding up one variant will slow down others, but never by much because it's rare that the CPU is the bottleneck anymore. It's far more likely to be the memory and IME you can more easily help the compiler optimise memory accesses by working on the original C/++ code. Doing (or with c99 'allowing') optimisations the compiler won't because it can't make assumptions that you think are obvious.
That BTW is what PGO does, it allows the compiler to go and check on assumptions it's not allowed to make, it can check aggressive aliasing rules or simplify function calling (or eliminate it by inlining between modules) or even making subroutines (not functions) for rarely used code. It's not a new optimisation method, just bigger.
NO program needs 4GB of code space you'd need of the order of 200 million lines of code in a single executable to get anywhere near it, so with that amount of address space available overlays are unnecessary.
Also very few programs need more that 4GB of data space. Before today I knew of only two Microsoft applications that would benefit from more that 2GB of data space; MS-SQL and MS-Exchange. Now it appears that that MS C++ compiler & linker could (very) occasionally benefit from a 64bit implementation ... but Microsoft aren't making a 64bit version of VS so it must be really rare as they're pushing hard for 64bit only.
As for assembly, it was quite a while ago now that C/C++ compliers became better assembly code generators than people. For a modern heavily optimising complier hand written assembler will usually perform worse than the code emitted by the compiler. Not least because of features like the "PGO" that's causing the problem for Firefox where the compiler is trying to find optimisations over the entire executable, not just for small regions of code.
If Microsoft encountered this problem while compiling a windows component they just turned PGO off. End of problem.
If I'm taking a computer run test I far prefer a single purpose machine, once, while taking a test I got the 'You must reboot windows now' popup.
Not a good experience!
we're not allowed to create special users or change the OS configuration
You're pretty much screwed as far as that OS is concerned. If you're really lucky there might be a copy of KDE installed with it's kiosk mode, or perhaps you can kill enough of the window manager to get it stuck (but that's supposed to result in the window manager restarting itself).
If you can't change the disk you're only option is to replace it. I don't mean physically, though that may be an option, I mean with live CD, usb or netboot
The Debian Live project allows you to easily create a live CD (or the other media) with your choice of packages; so easily in fact that there used to be an automatic service for it, upload the package list, download the ISO.
So install a minimal Debian with ONLY the bits you need turn it into a live image and boot it off the network.
No not Other Dave, he meant Proper Dave.
This Drive is CRAP
ASSUMING that it still only does read caching.
I bought one of the Gen-1 drives and was very underwhelmed. I wanted write caching; 4GB of non-volatile memory with the performance of SLC flash could allow windows (or whatever) to write to the drive flat out for up many seconds without a single choke due to the drive.
In addition 4G of write-back cache is enough to give a significant performance boost for continuous random writes across the drive and even more so across a small extent such as a database or a DotNET native image cache.
But for reading it's insignificant compared to the 3-16Gbytes of (so much faster) main memory that most systems contain, except at boot time when, unlike RAM, it will already contain some data. The problem with this is that it will contain the most recently read data, whereas the boot files can quite reasonably be described as least recently read.
So in the real world it's useless for anything except a machine that's rebooted every five minutes ...
If you tell Ubuntu to stop nagging it will, it'll either install everything or nothing, whichever you decide.
Windows on the other hand don't stop. If you tell it to install everything it still nags about some normal updates and updates to lawyereese and demands a reboot every time. If you tell it to just stop nagging it'll nag you that it's not allowed to nag if you disable that second nag there's yet another one. Then even if you get Windows itself to "shut up!!!" many so called anti-virus programs will start nagging and they don't stop till they're uninstalled. They you find something doesn't work because it needs one of the services you've disabled to stop the nagging ...
****!
Shouldn't be too long before the Mordor script "Tengwar" is formally accepted into unicode ...
But you still can't utter it here because slashcode is just a pile of ç, ÐоÐно, okay then U+7caa!
At least I can still call it cachu.
Basically their support is abominable and the >= 20Mb services are a lie.
Firstly the upstream is less than 10% of the downstream so the only way you can hope to fill the downstream is to 'tune' your IP stack to reduce the size of the ACK packets your stack replies with. Even then it's not likely.
Secondly they have a vicious 'peak time' data transfer limit that cripples your connection speed if you download something large, or watch a higher quality stream, in the later afternoon or evening.
And thirdly their router capacity is completely overloaded; most of the time you downloads are limited to around 500kbit/s per TCP channel due to the overloaded links on their network. For example, on another ISP I was able to download from Microsoft at over 10Mbit/s, but to get anywhere near Virgin's advertised 20Mbit/s I had to open 40 TCP connections.
So here I am at home with a reasonable 14Mbit/s ADSL and the ISP seems to have the uplinks to support it ... But I am changing soon, BSkyB have poor support and will only let you replace their shitty modems if you have the technical ability to browbeat them into submission. (ie: 45 minutes on the phone shooting down every suggestion and, politely, calling them morons.)
At work I did look into the fibre to the box option, what worried me most was the reliability question. The price was high, but it may have been worthwhile if it weren't on the bleeping edge. So in the end I got an Annex-M (2Mbit upstream) ADSL line from 'Be' (now part of O2). The support is good and they let you adjust the configuration of the line so you can choose what speed/reliability tradeoff you want. As we're literally a stones throw from the exchange (with a small catapult) I've turned everything "up to 11" and it's still fast and stable with a 13ms ping to google.
I doubt it. There was a story yesterday that 60% of malware found in the wild has no AV-software coverage.
Why should that be a surprise? AV software is installed on every vulnerable PC sold and even without updates it mostly protects against all the old threats. Even after that there is a pretty good chance it's infernal nagging for a credit card will get an updated AV installed, with or without a CC. The "mindshare" has been built, everybody believes that Windows must have anti-virus.
But, as has been said repeatedly the AV industry is reactive (though they are starting to try to solve the HARD problem of being intelligently proactive) so all an attacker has to do is make sure that the initial infection vector is obscure. If the initial infection disables the AV it can then download anything; including corpses of old viruses to blame and new updates to run with. The result is that the initial infecting agent will probably no longer exist on the machine, either the botnet will have been upgraded to the most recent version, which isn't yet on the the AV list, or the initial infector will be hidden away to try and stop it getting on the lists at all.
When I consider it, if I was in "the business", I'd be trying pretty hard to keep information out of the hands of the AV "white hats" and it wouldn't really be difficult, I'd just have to keep changing things to keep one step ahead.
U238 can be burnt in a reactor. Using reasonable growth models the U238 present on the Earth with last longer than it will take solar radiation to make the Earth uninhabitable.
It also won't require that most of the world's desert gets covered in solar cells.
Flash memory cannot be 'quick formatted' each block has to be properly erased before use because writing can only turn 1's into 0's. (Obviously, the filesystem on a flash device can be quick formatted; but a recent OS will tell the flash about this, using the "TRIM" command, and the flash will erase all the blocks anyway.)
Some flash drives even understand the NTFS filesystem well enough to erase unallocated blocks without help; but that seems a little dangerous to me.
BTW: What Kubiatowicz seems to be saying is that pulling electrons from the substrate into the gates of a flash drive makes it heavier. So erasing the blocks, ie shorting them to ground, makes them lighter. So while downloading a book could make the device lighter, erasing the device will make it lighter still.
It's the usual scenario, you pick the idiot:
1. OSS evangelist throws sales pitch at newbie
2. Newbie starts using OSS, tries to file a bug
3. "Scratch my own itch" developer tells him to get lost
That's easy; the "Newbie" didn't do his "caveat emptor".
Exactly the same things apply no matter how much you pay for a copy of software. If you were buying the physical medium (or paying the cost of a server) the price would be tiny or covered by the adverts (or something). What you're paying for is a bribe so the author will come back and do something to fix your problems or make something even better. With free software the author has stated they're not particularly interested in getting cash (or don't expect to get enough for it to be worthwhile) so you need another way of getting their attention.
Sometimes flattery works; but they tend to be pretty good at spotting saccharin. Of course a newbie bug report often starts off: "This software is crap!", this is not a good start. Other times nothing can work, because just a "bug report" is never enough, the developer has to be able to reproduce the problem. I expect this is the issue for the Linux kernel developers in respect of the virtualbox module. They never use the module, they use physical machines or kvm (and used to use vmware).
One last thing; don't let this put you off from sending bug reports, it may be that just the information you can send is enough for this bug, this gets much more likely if you can send an effective bug report.
Except when the web traffic is "P2P" of course; like it is whenever they say it is.
All net traffic is between two peers, this is a legal (and journo's) distinction without any real world (eg: technical) meaning. The closest you can get to what they really mean is probably that a company is paying for the machine you're connecting to not an individual.
So you couldn't possibly encode that in a filter which means you have to show 'best efforts', get some piece of software that promises to do the impossible and you're in a good position to defend when that accusation comes along.
Only if you use an extra pointer to point at the bytes of the string (so you can manufacture a string header anywhere at run time) or you copy your byte array to somewhere where there is some clear space before the string so that the library functions can find the length value where they expect it.
If you don't you'd have to have a complete set of special functions to use the different format constant strings or a special function call to convert the byte array plus length into a proper "string" structure.
In the end you'd waste more space dealing with the difference than you would just adding the fake string header in the first place.
He's underestimated the space cost. It's not just lose the NUL byte and gain an integer length, just encoding the current length in the type doesn't protect you from buffer overflows. For that you also need a maxstrlen integer.
So the size would be a length int, a maxlen int and the bytes of the string. But you're lucky, you see malloc holds a integer too for the length of the memory block it will free back into the pool, this can be overloaded with the maxstrlen field. So you're back to two bytes of overhead for a malloc'd string.
Constant strings are another matter, they don't have the malloc header so something else would have to be done. Probably the easiest would be to set the malloc length to zero, it's a constant after all so doesn't need to be freed or overwritten. That does mean 4.5 bytes overhead (including alignment) though.
The problem comes with buffers on the stack. These have a fixed chunk of memory allocated and so can't be expanded. But the malloc header we have for the strings explicitly can be expanded. There are two solutions; we could spend two more bytes and add a pointer to the base string structure then malloc the bytes for the string itself independently. A malloc'd string would be malloc's in two pieces doubling the malloc overhead and we'd have to do something about freeing this malloc'd space when the buffer goes out of scope ... I'm stuck, this isn't C anymore.
So the second choice goes right back to the start, the malloc size (maxstrlen) is now a hard limit; no library routine can expand it after it's been created. A string on the stack has a fake malloc header and the current string length (overheader 4.5 bytes). Of course there's the problem as to what to do if the string is too big; there are no exceptions, just truncation. (more, different, bugs)
So that's it the additional overhead is three bytes, not one, plus the alignment overhead. Two of the bytes (and the alignment) disappear with malloc'd strings but the added complexity stays.
And you don't even get dynamic strings.
This runs upto 20Mb/s; shared; less for long range. It's not for you.
If you want to give your subscribers 8Mb/s down and 0.8Mb/s upload at say 50:1 contention ratio that's "20000000 *50 / (1.1 * 8000000)", my calculator says 113 users, over a 62 mile radius.
It can handle 25 uploading at full speed (no problem) but only TWO downloading at full speed. BIG problem; you'd have to make sure you have a good router at the head that can share the bandwidth between customers not just TCP sessions. On a variable bandwidth connection too ... interesting times.
This bandwidth seems to be per former TV channel so you'll be able to multiply this up by however many TV channels you can use; as I recall that was only five or six within a given area because of interference from other transmitters. But it's better "out in the sticks".
So it looks like it's okay for getting some sort of internet connection to a house ten miles down a dirt track; but not much else at the ISP level.
As for mesh networking. One of the problems with broadcast is chattering network adaptors. One of the design criteria for this seem to be to maximise peak node to node bandwidth available. This means that a single chattering node will take out a substantial percentage of the available bandwidth perhaps all of it. As someone who has had to hunt down such an ethernet card back in the bad old days I truly pity anyone tasked with this job over a 12000sqmile area.
And I think you're wrong, there's no "rm" involved.
The removal is that the file details are being cleared from the memory cache and the cp is only looking in the cache for something it knew was there but hasn't locked yet. Because it wasn't locked another thread though it was a good candidate to be removed from the cache. The cp then assumed it was gone because something physically deleted it.
Okay, I guess that means Microsoft aren't as annoying as I thought they were.
Never mind :-)
I know, I'm not very good at propaganda. But like the best propaganda everything I said is true, however, I've tried to be 'complete', ie not take anything out of context.