The iPhone does have Skype now, you know. True, it's only allowed to work over the 802.11 connection, not the cellular, but it's definitely there.
Does it also work when you switch out of the Skype application? Which is, by the way, a separate application, not integrated into the main phone UI or the address book.
Us who live by YTV Reittiopas should now demand a standardised geolocation API in browser-side JavaScript, and its adoption by websites like this journey planner. Imagine, requesting a route from where you are now, at the click of a button. Web browsers in mobile devices make this possible.
Now, I've no idea if Skype has a license or not. They probably do, but I imagine that FSS guys aren't very happy about present state of affairs regardless...
Skype may have a termination agreement with some of the telephony/VoIP operators (which are obliged to provide hooks for wiretapping, indeed). But as the government let strong encryption out of the bag in the early 2000s - sorry, Putin, you can't roll back the history - they have absolutely no control over Skype p2p communications. Don't get distracted with this "national security" talk, the initiative is pure lobbying of our horse cart & buggy whip operators.
I haven't seen a security camera not privately installed in ages now, if ever.
Sure, it's installed and operated by private contractors, even if it's watching municipal property. Doesn't raise privacy concerns at all, does it.
You have to give your ID everywhere? Only times I need ID are when buying booze or other restricted items - and when I need to prove my identity. I can easily go months without showing my ID anywhere - given I don't drive and I stock up on the booze when I buy it.
Then you either pay in cash, or you don't ever buy more than 50 euro worth. But my point rather is, there is a single country-wide ID that is used to identify a person in every aspect of his or her relations to the government, and quite a few private institutions as well.
Finland is a very nice country to live in (if you don't mind some real seasons and 5pm sunsets in the winter), but I wouldn't point it out as a beacon of freedoms the poster seems to be asking for. Surveillance cameras are everywhere, you have to give your ID everywhere, and anyone can check your income by doing so much as sending an SMS.
To think of it, a military jet jock's operating procedure in the majority of serious emergencies probably says: "grab the ejection handle, brace yourself and pull". Civil aviators don't have this option.
What on Earth (or above) are you talking about? I remember Samoa or Fiji as the last chunk of land where people could wave the screaming burning pieces of Mir a good-bye.
Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.
So, you have never offered your libraries to an unknown number of third-party users in, say, a Linux distribution. When a problem is discovered in a library, the header-heavy "modern C++" approach would suggest telling the world to recompile. With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged. Also good for memory footprint, instruction cache pressure, startup time, and file sizes. Throw hardware at it as you wish, but your competitor may once outperform you on something that costs half as much.
You just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.
I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".
You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.
Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.
For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.
And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..
Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this.
Tell that to Erlang fans:) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.
Now thats amusing. Overwriting an old binary with a newer one is hard to do now?
Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.
Yes, I frequently use STL and Boost in embedded environments.
Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.
The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for their own errors.
The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
I did name the few that I feel are important. Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid. It tells you something when workable implementations lag years behind the approved standard.
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.
As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cause bloat and are rife with non-obvious "undefined behavior" (a byword in the C++ standard).
There are reasons why Qt does not submit to all "foundations for developing C++ code these days".
I have actually used some of the more massive meetings as an excuse to do some unobstructed coding (when I'm at my workplace, people always find me for something).
There's one other problem though: I'm prone to cursing out loud when I see something wrong or surprising in the code. Does not sound so well in a crowded auditorium...
I don't think of coffee as a cold-country drink at all, best coffees I've had have been in Spain, France, or California...
Yes, the coffee that is traditionally consumed here in the Nordics is vile percolated stuff. Espresso and friends are slowly taking hold, but most of the world's highest consumption is made up by the old hearty.
And there is a lot more that technically can be configured, but only by editing undocumented gconf settings -- and since they're undocumented, they are subject to change at any time.
What exactly do you mean by undocumented? GConf schemas always provided a way to document values, and most applications use it. The user can read these documentation snippets in gconf-editor. The format even has proper l10n (at a certain cost to installed file size).
If you mean nobody commits to the settings staying there under names unchanged between releases, I'd like to hear how KDE documents its configuration values for.ini files or what have they.
That "time interval of unknown length" was left in the spec for a reason. One possible reason I see is that untarring a large tree into a networked filesystem does not result in a massive amount of synchronous operations. And in ext3 the data vulnerability interval is still 5 seconds by default, not exactly zero.
Now, the real issue was people assuming the order of operations is preserved between changing the file data and changing the filesystem metadata. This is also an assumption taken beyond what the specification actually guarantees, one which restricts the way how the filesystem needs to be implemented with severe implications to performance, and this actually fails with a few modern filesystems besides ext4.
If you want transactions, use a DBMS. There are plenty out there which use fsync correctly. Try SQLite.
I feel this way too, but on the other hand I realise that in SQLite fsync is done at every commit, and this means also every database query not in an explicit transaction. Which is what clueless developers tend to use all the time, with the result of SQLite becoming a bane of SSDs.
In quite recent Mozilla versions, every link click caused an fsync. Many people started blaming SQLite and/or fsync implementation on ext3 in doing things the "slow" way, while the right question actually was, does the user really need browser history always persisted to the last click.
So basically they can easily lay cable from and to the site, and they can have excellent connections to Russia without actually having to place the hardware there. (Not that I'm sure it would be an issue these days.)
Of course it would, when FSB comes after their hard drives for hosting the opposition on Blogger.
And yes, some of the fattest bit pipes connecting Russia to the world go through Finland.
It's not like Java is outputting some sort of magical instructions that are different from the output of compiled C. The difference is that C doesn't abstract the hardware layer in the user code like Java does, and that Java is compiled to be interpreted on the fly by an intermediate virtual runtime environment.
You almost said it yourself. C doesn't abstract things like processes, so you cannot change the implementation of the OS in interesting ways without modifying all the applications. With the entire system as a virtual machine, you have greater freedom of implementation, while the application code may last.
Meh. Another we-are-all-gonna-die-but-the-main-guy-has-to-save-his-family flick. I remember they've made a couple of them in one year.
The iPhone does have Skype now, you know. True, it's only allowed to work over the 802.11 connection, not the cellular, but it's definitely there.
Does it also work when you switch out of the Skype application? Which is, by the way, a separate application, not integrated into the main phone UI or the address book.
Us who live by YTV Reittiopas should now demand a standardised geolocation API in browser-side JavaScript, and its adoption by websites like this journey planner. Imagine, requesting a route from where you are now, at the click of a button. Web browsers in mobile devices make this possible.
we really have no idea how many cosmonauts died during the Soviet program.
Four.
Now, I've no idea if Skype has a license or not. They probably do, but I imagine that FSS guys aren't very happy about present state of affairs regardless...
Skype may have a termination agreement with some of the telephony/VoIP operators (which are obliged to provide hooks for wiretapping, indeed). But as the government let strong encryption out of the bag in the early 2000s - sorry, Putin, you can't roll back the history - they have absolutely no control over Skype p2p communications. Don't get distracted with this "national security" talk, the initiative is pure lobbying of our horse cart & buggy whip operators.
I haven't seen a security camera not privately installed in ages now, if ever.
Sure, it's installed and operated by private contractors, even if it's watching municipal property. Doesn't raise privacy concerns at all, does it.
You have to give your ID everywhere? Only times I need ID are when buying booze or other restricted items - and when I need to prove my identity. I can easily go months without showing my ID anywhere - given I don't drive and I stock up on the booze when I buy it.
Then you either pay in cash, or you don't ever buy more than 50 euro worth.
But my point rather is, there is a single country-wide ID that is used to identify a person in every aspect of his or her relations to the government, and quite a few private institutions as well.
Finland is a very nice country to live in (if you don't mind some real seasons and 5pm sunsets in the winter), but I wouldn't point it out as a beacon of freedoms the poster seems to be asking for. Surveillance cameras are everywhere, you have to give your ID everywhere, and anyone can check your income by doing so much as sending an SMS.
It's the only way to be sure.
To think of it, a military jet jock's operating procedure in the majority of serious emergencies probably says: "grab the ejection handle, brace yourself and pull". Civil aviators don't have this option.
That's exactly the decision made by the crew of Pulkovo flight 612. No commercial pressure can outweigh the deadly risk.
What on Earth (or above) are you talking about?
I remember Samoa or Fiji as the last chunk of land where people could wave the screaming burning pieces of Mir a good-bye.
Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.
So, you have never offered your libraries to an unknown number of third-party users in, say, a Linux distribution. When a problem is discovered in a library, the header-heavy "modern C++" approach would suggest telling the world to recompile. With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged. Also good for memory footprint, instruction cache pressure, startup time, and file sizes. Throw hardware at it as you wish, but your competitor may once outperform you on something that costs half as much.
You just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.
I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".
You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.
Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.
For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.
And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..
Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this.
Tell that to Erlang fans :) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.
Now thats amusing. Overwriting an old binary with a newer one is hard to do now?
Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.
Yes, I frequently use STL and Boost in embedded environments.
Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.
The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for
their own errors.
The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.
Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.
I did name the few that I feel are important.
Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid. It tells you something when workable implementations lag years behind the approved standard.
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.
As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cause bloat and are rife with non-obvious "undefined behavior" (a byword in the C++ standard).
There are reasons why Qt does not submit to all "foundations for developing C++ code these days".
I have actually used some of the more massive meetings as an excuse to do some unobstructed coding (when I'm at my workplace, people always find me for something).
There's one other problem though: I'm prone to cursing out loud when I see something wrong or surprising in the code. Does not sound so well in a crowded auditorium...
I don't think of coffee as a cold-country drink at all, best coffees I've had have been in Spain, France, or California...
Yes, the coffee that is traditionally consumed here in the Nordics is vile percolated stuff. Espresso and friends are slowly taking hold, but most of the world's highest consumption is made up by the old hearty.
And there is a lot more that technically can be configured, but only by editing undocumented gconf settings -- and since they're undocumented, they are subject to change at any time.
What exactly do you mean by undocumented? GConf schemas always provided a way to document values, and most applications use it. The user can read these documentation snippets in gconf-editor. The format even has proper l10n (at a certain cost to installed file size).
If you mean nobody commits to the settings staying there under names unchanged between releases, I'd like to hear how KDE documents its configuration values for .ini files or what have they.
Actually, polonium was named after Poland by Marie Sklodowska-Curie.
That "time interval of unknown length" was left in the spec for a reason. One possible reason I see is that untarring a large tree into a networked filesystem does not result in a massive amount of synchronous operations. And in ext3 the data vulnerability interval is still 5 seconds by default, not exactly zero.
Now, the real issue was people assuming the order of operations is preserved between changing the file data and changing the filesystem metadata. This is also an assumption taken beyond what the specification actually guarantees, one which restricts the way how the filesystem needs to be implemented with severe implications to performance, and this actually fails with a few modern filesystems besides ext4.
If you want transactions, use a DBMS. There are plenty out there which use fsync correctly. Try SQLite.
I feel this way too, but on the other hand I realise that in SQLite fsync is done at every commit, and this means also every database query not in an explicit transaction. Which is what clueless developers tend to use all the time, with the result of SQLite becoming a bane of SSDs.
In quite recent Mozilla versions, every link click caused an fsync. Many people started blaming SQLite and/or fsync implementation on ext3 in doing things the "slow" way, while the right question actually was, does the user really need browser history always persisted to the last click.
Also, you can co-locate your data center with a sauna/spa center and always have a grateful clientele whom you'll warm for free!
Now, the story about Google buying a disused paper mill in Hamina is starting to make sense... Google Saunamaailma, here I come!
This article rather reminded me of something from Cryptonomicon:
"How many slums will we bulldoze to build the Information Superhighway?"
Prooflink?
So basically they can easily lay cable from and to the site, and they can have excellent connections to Russia without actually having to place the hardware there. (Not that I'm sure it would be an issue these days.)
Of course it would, when FSB comes after their hard drives for hosting the opposition on Blogger.
And yes, some of the fattest bit pipes connecting Russia to the world go through Finland.
Good subject, heh :)
It's not like Java is outputting some sort of magical instructions that are different from the output of compiled C. The difference is that C doesn't abstract the hardware layer in the user code like Java does, and that Java is compiled to be interpreted on the fly by an intermediate virtual runtime environment.
You almost said it yourself. C doesn't abstract things like processes, so you cannot change the implementation of the OS in interesting ways without modifying all the applications. With the entire system as a virtual machine, you have greater freedom of implementation, while the application code may last.