Except that we're talking about C++, WinRT doesn't have C++ bindings in any of Microsoft's languages. There is something called C++/CX, which is a yet another language incompatible with anything else (and somehow advertised by Microsoft as real C++).
VC++ is not a C99 compiler; deal with it. It's a C++03/11 compiler with accidental support for C99 stuff - hence no inttypes.h etc
C++11 requires them.
all Win32 APIs (and now also WinRT APIs) use UTF-16 rather than UCS2 - so characters above U+FFFF work just fine
Except where they don't, and that seems to be the majority of calls I used recently. For example, all console calls (WriteConsoleOutput(), etc). Or, character classification (iswupper(), towupper()).
If you really want UTF-8, though, you can have that as well (codepage 65001).
This is supported only in a couple of conversion functions, you can't do I/O, fopen(), etc via it. Lengthier discussion.
Mostly a waste of time -- instead of wrangling with just a bizarre platform, you need to fight both a bizarre platform and a bizarre compiler.
Microsoft keeps doing strange things with no obvious purpose other than reducing portability. For example, using their proprietary APIs where a better ANSI C version already exists. Or, using a two-byte encoding instead of UTF-8 (this breaks characters above U+FFFF, with badly incomplete hacks to re-fix them, C++ streams, etc). Or, those "security enhanced" replacements for most ANSI C functions that are actually less secure than originals (fopen_s(), etc). All while withholding basic standard features, like inttypes.h.
If you're developing something Windows-only, MSVC might be adequate, but for anything portable, forget it.
You can't use a browser without adblock these days and retain sanity. And unless you decide to throw away your privacy, you'll block trackers like Google Analytics or StatCounter.
So join me on the mission: drive apparent Firefox usage stats to 0.
The issue was, POSIX does not guarantee any ordering of writes unless you call fsync(). A lot of folks wrongly thought that writing a new version of a file, closing it then renaming over the old name is perfectly safe and atomic, guaranteeing there's either the old version or the new one. The rename call indeed guarantees that the directory has either both the old and temp file, or only the new one, but does not say anything about the new file's contents -- you need to at least fdatasync() it.
So unless a new barrier call is added, there is no way around fsync() - and the ext3 slowness that was after big flamewars ported to ext4 is the kernel fsyncing stuff behind your back even if you don't request it, to pander to buggy code.
I don't know what MythTV keeps fsycing for, but I guess they had something that requires consistency, which currently can't be done without fsync. All you can do are clever tricks like WAL in sqlite, or filesystem specific calls like btrfs' features.
It's long overdue for POSIX to get a call that says: "all writes to descriptor A which happened before must be no less durable than all future writes to descriptor B (possibly A == B)". This way, it's possible that after a crash neither A nor B hits the platters, A but not B, or both -- but it's impossible to get B but not A. Such a call has been proposed a few times, but never actually got added.
When spying on your own family (you asshole!), you have access to client computers, and can install your own SSL certificates, or an outright keylogger. Common software can detect keyloggers and that can get you into trouble when shit hits the fan, so a SSL certificate with a proxy on the router, while being more Rube Goldbergesque, is safer.
(Sorry for potentially helping a home despot, but in order to be secure, you need to know what the enemy can do, so hiding this discussion wouldn't help.)
Re:btrfs needed the work
on
Linux 3.4 Released
·
· Score: 4, Informative
Yes, there is a massive speed difference. Unpacking a particular tarball takes 10 seconds on btrfs, 124 seconds on ext4.
The problem is with certain broken programs that fsync after every single write. But that's a problem with those programs, not btrfs. The words "fsync" and "performance" don't belong in the same sentence. fsync may be legitimately uses when durability is actually needed, but in almost all use cases the programs want only consistency.
An example: there's a file where a transaction consists of appending a few bytes to the file then updating something in the header. Let's say it's four bytes in both writes. The program can handle power loss between transactions or if it happens between the first write and a header update, but not any other reordering. The disk in question has 100MB linear speed and 10ms seek time. Even with some kind of a barrier syscall, ext4 would need to alternate writes anyway, plus it needs to write to the journal and inode. This gives you a whooping 25 transaction per second. btrfs and log-structured filesystems with atomic flushes get 25M instead (assuming infinitely fast CPU).
The primary offender here is Firefox which fsyncs all the time. This not only slows down writes but also causes insane fragmentation. The data it protects is not vital in the first place (mostly browsing history), and if it used sqlite in WAL mode on relevant platforms instead it wouldn't have to fsync for consistency almost at all.
Even if you don't sign up to Facebook, they are tracking you because of their little F icon and/or scripts/cookies are being loaded up by your web browser on any webpage you are visiting.
Nobody says you have to click the little F icon!
Even if you don't click that F icon, they still track you.
Blocking referer on third-party requests helps (and should be mandatory in all decent browsers! (ext for FF)), but really, unless you adblock all of {facebook,fb,fbcdn}.{com,net} and probably more, Facebook will get a lot of data about you and your browsing patterns even if you don't use it.
Not the first time something like this happened. The tsars used to draw foreign engineers, usually from Germany, to modernize the country, and when the engineers asked "should the railroad gauge be like ours, or bigger?", the tsar answered with a common Russian expletive, "for a dick bigger?". And so it stuck...
By default, do you mean a C++ default parameter value or setting it to NULL? Judging by the warning it looks like you have asked the compiler to analyse the parameter as a format string then proceeded to pass NULL which is not a valid format string. In other words, it's PEBKAC.
It is a literal, and thus, contrary to what the warning claims, there's no possible security error. It also makes sense if the message is optional.
But that's beside the point. Even if the warning was correct, clang fails to point out where it happens, not letting you fix it without bisecting the whole file which may be hard to do.
GCC always shows the offending line, clang does not.
For example, if you have a printf()-like function whose format string has a default value, every use will emit: warning: format string is not a string literal (potentially insecure) [-Wformat-security] without a mention of the line in question. The default value here is also a literal, making the whole warning bogus in the first place.
Only in the strictly monetary sense. For about anything else, including NSA's stated purpose of providing security for the nation, it goes against the taxpayers as they are either citizens or legal aliens who live in the country.
The old saying is: "What Intel giveth, Microsoft taketh away."
As long as all the functionality you want is there, replacing the thing is a pure waste of money: there's a cost but no gain. Of course, there's stuff like trying to run a new browser on a phone just two years old, but new software on old metal is the worst you can get.
Resolution isn't a problem as any decent browser can seamlessly scale stuff. It's mostly about screen proportions, and you just happen to have the best (barely) available one for about any kind of work other than watching cinema movies. I'd take a 4x3 (or 3x4!) screen of a shitty resolution over something 16x10 or worse.
Certain extensions, and a good deal of programs other than browsers fail to obey size scaling settings, though, so resolution is still nice to have (besides less eyestrain). It's almost always about vertical resolution though, again.
Remember XHTML? Remember exported templates in C++?
This kind of experimental features are better done _marked_ as experimental, so they don't need to be supported forever. So I'd go the totally opposite way: force using such prefixes, and request browser makers to drop support X time after a feature is accepted into the standard.
Actually, Unicode became a widely implemented standard only in the first few years of this millennium. And while for most of the world the replacement is complete, there are a few shameless places that still use ancient charsets. Fix it, Microsoft and Slashdot!
You don't matter, meatbag. Only your genes do. You're merely a tool used by them to survive. And reproduction proven to be a far better survival strategy than having a single host live forever.
This is the fifth story[1] based on a single article by one single shill. If this were mere trolling, I'd be grudgingly impressed. As this is a commercial scheme, I hate the guy with passion.
[1]. counting only those I noticed and remember, so there's probably more.
This is pretty similar to the information theory proof that if a god exist, he cannot simultaneously be omniscient and be a part of the universe. It still leaves the possibility of a god outside the universe (ie, lacking full self-awareness), like a programmer watching a simulation from outside a computer.
Slashdot Mirror
WinRT APIs
Except that we're talking about C++, WinRT doesn't have C++ bindings in any of Microsoft's languages. There is something called C++/CX, which is a yet another language incompatible with anything else (and somehow advertised by Microsoft as real C++).
VC++ is not a C99 compiler; deal with it. It's a C++03/11 compiler with accidental support for C99 stuff - hence no inttypes.h etc
C++11 requires them.
all Win32 APIs (and now also WinRT APIs) use UTF-16 rather than UCS2 - so characters above U+FFFF work just fine
Except where they don't, and that seems to be the majority of calls I used recently. For example, all console calls (WriteConsoleOutput(), etc). Or, character classification (iswupper(), towupper()).
If you really want UTF-8, though, you can have that as well (codepage 65001).
This is supported only in a couple of conversion functions, you can't do I/O, fopen(), etc via it. Lengthier discussion.
Mostly a waste of time -- instead of wrangling with just a bizarre platform, you need to fight both a bizarre platform and a bizarre compiler.
Microsoft keeps doing strange things with no obvious purpose other than reducing portability. For example, using their proprietary APIs where a better ANSI C version already exists. Or, using a two-byte encoding instead of UTF-8 (this breaks characters above U+FFFF, with badly incomplete hacks to re-fix them, C++ streams, etc). Or, those "security enhanced" replacements for most ANSI C functions that are actually less secure than originals (fopen_s(), etc). All while withholding basic standard features, like inttypes.h.
If you're developing something Windows-only, MSVC might be adequate, but for anything portable, forget it.
You can't use a browser without adblock these days and retain sanity. And unless you decide to throw away your privacy, you'll block trackers like Google Analytics or StatCounter.
So join me on the mission: drive apparent Firefox usage stats to 0.
The issue was, POSIX does not guarantee any ordering of writes unless you call fsync(). A lot of folks wrongly thought that writing a new version of a file, closing it then renaming over the old name is perfectly safe and atomic, guaranteeing there's either the old version or the new one. The rename call indeed guarantees that the directory has either both the old and temp file, or only the new one, but does not say anything about the new file's contents -- you need to at least fdatasync() it.
So unless a new barrier call is added, there is no way around fsync() - and the ext3 slowness that was after big flamewars ported to ext4 is the kernel fsyncing stuff behind your back even if you don't request it, to pander to buggy code.
I don't know what MythTV keeps fsycing for, but I guess they had something that requires consistency, which currently can't be done without fsync. All you can do are clever tricks like WAL in sqlite, or filesystem specific calls like btrfs' features.
It's long overdue for POSIX to get a call that says: "all writes to descriptor A which happened before must be no less durable than all future writes to descriptor B (possibly A == B)". This way, it's possible that after a crash neither A nor B hits the platters, A but not B, or both -- but it's impossible to get B but not A. Such a call has been proposed a few times, but never actually got added.
When spying on your own family (you asshole!), you have access to client computers, and can install your own SSL certificates, or an outright keylogger. Common software can detect keyloggers and that can get you into trouble when shit hits the fan, so a SSL certificate with a proxy on the router, while being more Rube Goldbergesque, is safer.
(Sorry for potentially helping a home despot, but in order to be secure, you need to know what the enemy can do, so hiding this discussion wouldn't help.)
Yes, there is a massive speed difference. Unpacking a particular tarball takes 10 seconds on btrfs, 124 seconds on ext4.
The problem is with certain broken programs that fsync after every single write. But that's a problem with those programs, not btrfs. The words "fsync" and "performance" don't belong in the same sentence. fsync may be legitimately uses when durability is actually needed, but in almost all use cases the programs want only consistency.
An example: there's a file where a transaction consists of appending a few bytes to the file then updating something in the header. Let's say it's four bytes in both writes. The program can handle power loss between transactions or if it happens between the first write and a header update, but not any other reordering. The disk in question has 100MB linear speed and 10ms seek time. Even with some kind of a barrier syscall, ext4 would need to alternate writes anyway, plus it needs to write to the journal and inode. This gives you a whooping 25 transaction per second. btrfs and log-structured filesystems with atomic flushes get 25M instead (assuming infinitely fast CPU).
The primary offender here is Firefox which fsyncs all the time. This not only slows down writes but also causes insane fragmentation. The data it protects is not vital in the first place (mostly browsing history), and if it used sqlite in WAL mode on relevant platforms instead it wouldn't have to fsync for consistency almost at all.
Even if you don't sign up to Facebook, they are tracking you because of their little F icon and/or scripts/cookies are being loaded up by your web browser on any webpage you are visiting.
Nobody says you have to click the little F icon!
Even if you don't click that F icon, they still track you.
Blocking referer on third-party requests helps (and should be mandatory in all decent browsers! (ext for FF)), but really, unless you adblock all of {facebook,fb,fbcdn}.{com,net} and probably more, Facebook will get a lot of data about you and your browsing patterns even if you don't use it.
Not the first time something like this happened. The tsars used to draw foreign engineers, usually from Germany, to modernize the country, and when the engineers asked "should the railroad gauge be like ours, or bigger?", the tsar answered with a common Russian expletive, "for a dick bigger?". And so it stuck...
By default, do you mean a C++ default parameter value or setting it to NULL? Judging by the warning it looks like you have asked the compiler to analyse the parameter as a format string then proceeded to pass NULL which is not a valid format string. In other words, it's PEBKAC.
It is a literal, and thus, contrary to what the warning claims, there's no possible security error. It also makes sense if the message is optional.
But that's beside the point. Even if the warning was correct, clang fails to point out where it happens, not letting you fix it without bisecting the whole file which may be hard to do.
Haven't you read the very page you linked to?
scan-build [...] executes either clang or gcc
GCC always shows the offending line, clang does not.
For example, if you have a printf()-like function whose format string has a default value, every use will emit:
warning: format string is not a string literal (potentially insecure) [-Wformat-security]
without a mention of the line in question. The default value here is also a literal, making the whole warning bogus in the first place.
5) It is beneficial to taxpayers
Only in the strictly monetary sense. For about anything else, including NSA's stated purpose of providing security for the nation, it goes against the taxpayers as they are either citizens or legal aliens who live in the country.
Yes, it could, although I hope they can do it better than the AI used to edit and post this story.
The old saying is: "What Intel giveth, Microsoft taketh away."
As long as all the functionality you want is there, replacing the thing is a pure waste of money: there's a cost but no gain.
Of course, there's stuff like trying to run a new browser on a phone just two years old, but new software on old metal is the worst you can get.
Resolution isn't a problem as any decent browser can seamlessly scale stuff. It's mostly about screen proportions, and you just happen to have the best (barely) available one for about any kind of work other than watching cinema movies. I'd take a 4x3 (or 3x4!) screen of a shitty resolution over something 16x10 or worse.
Certain extensions, and a good deal of programs other than browsers fail to obey size scaling settings, though, so resolution is still nice to have (besides less eyestrain). It's almost always about vertical resolution though, again.
Remember XHTML? Remember exported templates in C++?
This kind of experimental features are better done _marked_ as experimental, so they don't need to be supported forever. So I'd go the totally opposite way: force using such prefixes, and request browser makers to drop support X time after a feature is accepted into the standard.
What click counters, "+1 this" or "digg this" are you talking about? I guess you failed step 2 of installing a browser.
Actually, Unicode became a widely implemented standard only in the first few years of this millennium. And while for most of the world the replacement is complete, there are a few shameless places that still use ancient charsets. Fix it, Microsoft and Slashdot!
Considering they can't tell the difference between the hash/number sign and sharp, I wouldn't want to come anywhere near that skyscraper.
You don't matter, meatbag. Only your genes do. You're merely a tool used by them to survive. And reproduction proven to be a far better survival strategy than having a single host live forever.
This is the fifth story[1] based on a single article by one single shill. If this were mere trolling, I'd be grudgingly impressed. As this is a commercial scheme, I hate the guy with passion.
[1]. counting only those I noticed and remember, so there's probably more.
You mean, breaking out of a sandbox has no security-breaching uses?
This is pretty similar to the information theory proof that if a god exist, he cannot simultaneously be omniscient and be a part of the universe. It still leaves the possibility of a god outside the universe (ie, lacking full self-awareness), like a programmer watching a simulation from outside a computer.
Ie, he's the second Obama, where the only "change" was changing his promises, right?