Yes. But if you need to make a quick tool which generates a litttle of customized source to copy into a file, then tcl can be very practical (which is why it appears in many toolchains).
Using native code was never something which contradicted using scripting languages (in my case: python, perl, matlab, tcl) or java. Mixing them in the right way does the trick.
My approach was: use whatever tool is suitable. Write native what needs to be done native (and preferably use ANSI C for it), write guis in (preferably java or tcl).
Exactly its backed by the fact that people will sell you something for it. But more important it is backed by the fact that it is the legal way of paying things in the USA, which means you will be able to buy things for quite some time. There will be a need for Dollars, because the US government needs dollars.
No matter how many bitcoins you have, you cant pay your taxes with them. You cant lend bitcoins to the government, but dollars.
Another thing is that the dollar is produced in arbitrary nontransparent amounts. Printed dollars should (in average) correspond to the expansion of the US economy.
This means if i own dollars i roughly know what i will have tomorrow. if i have bitcoins i wont.
I am not sure. But everybody with a little bit of real understanding should know that bitcoin is a fucked idea. It wont work, for a number of reasons.
The most important one is that the creation of a bitcoin is *not* backed by anything. It burns computational power for nothing. But just using energy to produce it does not input *value* in the same way in which printing a bill or forging a coin does not produce any value.
It only links the the will to back this money to whoever puts his name on it.
There would be a number of ways to introduce a valid digital currency, but bitcoin is just a senseless ponzi-scheme for wannabe hackers.
Call your bank and ask them to use a trustworthy CA.
IMHO thw browser should ask you when started the first time which organizations should be trusted to, with a brief explanation and the number of certificates singed by this organization.
My experience is: you can use an android phone (galazy tab) without a login to google, also the contacts and the calendar work. But everything which is synchronization is a pain in the ass because it relies on the google account and the built-in support keeps market alternatives a little bit down.
Ahem, am i screwed because my browser issues a warning to me? Or should this the big red sign be enough to inform me that i should not enter account information or confidential email there?
If its important enough to me, then i can verify the fingerprint of the certificate myself.
If security is very important to you, then hand-pick the CAs you trust. Thats like in real life. Normally its probably enough to look at the drivers license to check who is in front of you, however dont rely on that if you need extra security.
>> HTML5 hard truth No. 1: Security is a nightmare The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.
Relying on the client not being able to understand the executed code is not even security by obscurity but even worse. Relying on client-side checks for consistent data (or even authorization - yes i have seen that) was stupid since the beginning of the web (and before).
Layer your spheres of access correctly, and there will be no bigger problem
> HTML5 hard truth No. 2: Local data storage is limited
Local storage is *always* limited. Relying on having near infinite local storage is something which also pisses me off for Desktop apps.
> HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up, or open it with a different app. It's all buried deep where the browser hides it.
You is the user or the service provider? And *nobody* hinders you to implement also local backup mechanisms and free export of the data for the user. If you dont have the creativity or the knowledge to do so, then dont the fuck try to write a serious application. And if you back up you machine, your browser data is backed up with it.
> Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.
Wow. As if the average Desktop application would have completely open, understandable and easy to read data formats.....
>HTML5 hard truth No. 3: Local data can be manipulated
Uhm. did we talk about the server-side consistency check. And if its (according to the Truth Nr. 4) so much easier in the case of a pure desktop application to edit the data would that be not better in the sense of Truth Nr. 5?
> HTML5 hard truth No. 4: Offline apps are a nightmare to sync
Yes, always. Hasnt a single thing to do with HTML5
> HTML5 hard truth No. 5: The cloud owes you nothing It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.
The cloud is *not* an essential part of "the vision" of HTML5. It is a promising approach to deliver services cheap, HTML5 or not.
HTML5 hard truth No. 6: Forced upgrades aren't for everyone
Forced upgrades? We never had these before....
What is this. Sony forces updates to the PS. MS forces the installation of the WGA. Whe web-mail providers i use update senselessly all the time, since 10 years.
HTML5 hard truth No. 7: Web Workers offer no prioritization
A well written program relies on message passing and not polling. As a programmer i seldom had to prioritze threads withing an application.
HTML5 hard truth No. 8: Format incompatibilities abound
Yes, thats sad. The standard is still in the flow.
HTML5 hard truth No. 9: Implementations are browser-dependent
html has been browser-dependent since a long time, and so was java (not badly). Native applications are OS-dependent.
So what. An IT professional who thought that HTML5 would be the magic wand to overcome incompatibilities between environments with testing would have been stupid.
HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges
Funny. What you want to say: make a 3d game and it wont run as well on a handheld device without acceleration? Yes, that has been pretty much my experience the last 20 years.
Its kind of an interesting approach. Open a system, distribute it for free, buy the company which made one of the best devices out of it. If google would be oracle the next step would be to cut down the distribution of the system or ask for money......
Right. And by having the source code, scripts written for hundreds of use cases magically check and correct themselves.
The parent *is* right. It helps if the version numbering consistently indicates whats going on. Being lazy and trying to rely on this has means not consuming too much hours for getting things done. And its sad. If i would know that upgrading a linux machine or connecting new versions to a environment is unpredictable in a way which makes me consume too-many extra hours for nothing (instead of using these to check when the real changes arrive), then i would have to recommend Windows or Solaris.
Well to me it seems (sssuming he does not lie) a fair description.
From what he says i gather: use it for web-surfing and simple email and it works ok. But the same would be probably true for any system with a slightly revamped ui for firefox and thunderbird.
What i dont understand why he does not comment that a computer like this probably would better have a 32G flash drive that a 500G hard drive. A beginner not doing many photos, downloading/editing movies, installing several virtual machines, or having the 1000CD-collection in lossless on the harddrive wont use this space and it may be more susceptible to movements and slower.
Yes, but in the case of not being checked he also could hand over weapons to possible terrorists inside the security zone and they could do the attack.
There is a difference between having to kill yourself to do the attack or smuggling in weapons for money.
Slashdot Mirror
Because real artists ship.
Yes. But if you need to make a quick tool which generates a litttle of customized source to copy into a file, then tcl can be very practical (which is why it appears in many toolchains).
I just see the last software designed by palm sinking. All which i have now as a memory is the port of graffiti as an input method for android.
Using native code was never something which contradicted using scripting languages (in my case: python, perl, matlab, tcl) or java. Mixing them in the right way does the trick.
My approach was: use whatever tool is suitable. Write native what needs to be done native (and preferably use ANSI C for it), write guis in (preferably java or tcl).
I still hope IBM ports it to linux some day...
No, they fetch their friends which arrive in NO_SUCH_AUTOMOBILE
Tampering is not needed for taking a thermal photo as the next in line.
Exactly its backed by the fact that people will sell you something for it. But more important it is backed by the fact that it is the legal way of paying things in the USA, which means you will be able to buy things for quite some time. There will be a need for Dollars, because the US government needs dollars.
No matter how many bitcoins you have, you cant pay your taxes with them. You cant lend bitcoins to the government, but dollars.
Another thing is that the dollar is produced in arbitrary nontransparent amounts. Printed dollars should (in average) correspond to the expansion of the US economy.
This means if i own dollars i roughly know what i will have tomorrow. if i have bitcoins i wont.
I am not sure. But everybody with a little bit of real understanding should know that bitcoin is a fucked idea. It wont work, for a number of reasons.
The most important one is that the creation of a bitcoin is *not* backed by anything. It burns computational power for nothing. But just using energy to produce it does not input *value* in the same way in which printing a bill or forging a coin does not produce any value.
It only links the the will to back this money to whoever puts his name on it.
There would be a number of ways to introduce a valid digital currency, but bitcoin is just a senseless ponzi-scheme for wannabe hackers.
Call your bank and ask them to use a trustworthy CA.
IMHO thw browser should ask you when started the first time which organizations should be trusted to, with a brief explanation and the number of certificates singed by this organization.
My experience is: you can use an android phone (galazy tab) without a login to google, also the contacts and the calendar work. But everything which is synchronization is a pain in the ass because it relies on the google account and the built-in support keeps market alternatives a little bit down.
Ahem, am i screwed because my browser issues a warning to me? Or should this the big red sign be enough to inform me that i should not enter account information or confidential email there?
If its important enough to me, then i can verify the fingerprint of the certificate myself.
If security is very important to you, then hand-pick the CAs you trust. Thats like in real life. Normally its probably enough to look at the drivers license to check who is in front of you, however dont rely on that if you need extra security.
i get a decent software for updating the galaxy tab?
>> HTML5 hard truth No. 1: Security is a nightmare The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.
Relying on the client not being able to understand the executed code is not even security by obscurity but even worse. Relying on client-side checks for consistent data (or even authorization - yes i have seen that) was stupid since the beginning of the web (and before).
Layer your spheres of access correctly, and there will be no bigger problem
> HTML5 hard truth No. 2: Local data storage is limited
Local storage is *always* limited. Relying on having near infinite local storage is something which also pisses me off for Desktop apps.
> HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up, or open it with a different app. It's all buried deep where the browser hides it.
You is the user or the service provider? And *nobody* hinders you to implement also local backup mechanisms and free export of the data for the user. If you dont have the creativity or the knowledge to do so, then dont the fuck try to write a serious application. And if you back up you machine, your browser data is backed up with it.
> Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.
Wow. As if the average Desktop application would have completely open, understandable and easy to read data formats.....
>HTML5 hard truth No. 3: Local data can be manipulated
Uhm. did we talk about the server-side consistency check. And if its (according to the Truth Nr. 4) so much easier in the case of a pure desktop application to edit the data would that be not better in the sense of Truth Nr. 5?
> HTML5 hard truth No. 4: Offline apps are a nightmare to sync
Yes, always. Hasnt a single thing to do with HTML5
> HTML5 hard truth No. 5: The cloud owes you nothing It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.
The cloud is *not* an essential part of "the vision" of HTML5. It is a promising approach to deliver services cheap, HTML5 or not.
HTML5 hard truth No. 6: Forced upgrades aren't for everyone
Forced upgrades? We never had these before....
What is this. Sony forces updates to the PS. MS forces the installation of the WGA. Whe web-mail providers i use update senselessly all the time, since 10 years.
HTML5 hard truth No. 7: Web Workers offer no prioritization
A well written program relies on message passing and not polling. As a programmer i seldom had to prioritze threads withing an application.
HTML5 hard truth No. 8: Format incompatibilities abound
Yes, thats sad. The standard is still in the flow.
HTML5 hard truth No. 9: Implementations are browser-dependent
html has been browser-dependent since a long time, and so was java (not badly). Native applications are OS-dependent.
So what. An IT professional who thought that HTML5 would be the magic wand to overcome incompatibilities between environments with testing would have been stupid.
HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges
Funny. What you want to say: make a 3d game and it wont run as well on a handheld device without acceleration? Yes, that has been pretty much my experience the last 20 years.
HTML5 hard truth No. 11: Politics as usual
Honestly? An HTML5 only problem? Well....
Yes, exactly. And often enough in the seven years things were breaking.
Its kind of an interesting approach. Open a system, distribute it for free, buy the company which made one of the best devices out of it. If google would be oracle the next step would be to cut down the distribution of the system or ask for money......
Right. And by having the source code, scripts written for hundreds of use cases magically check and correct themselves.
The parent *is* right. It helps if the version numbering consistently indicates whats going on. Being lazy and trying to rely on this has means not consuming too much hours for getting things done. And its sad. If i would know that upgrading a linux machine or connecting new versions to a environment is unpredictable in a way which makes me consume too-many extra hours for nothing (instead of using these to check when the real changes arrive), then i would have to recommend Windows or Solaris.
Ouch. Uninformed.
and SX had a 16 bit data *bus* and AFAIR an restricted adress bus (it could not adress 4GB physical memory).
and DX was 32 bit also on the physical data bus.
it had no coprocessor on chip (that was the 387, to be bought separately)
in contrast the 486SX was a 486DX with a disabled (broken AFAIR) coprocessor
Well to me it seems (sssuming he does not lie) a fair description.
From what he says i gather: use it for web-surfing and simple email and it works ok. But the same would be probably true for any system with a slightly revamped ui for firefox and thunderbird.
What i dont understand why he does not comment that a computer like this probably would better have a 32G flash drive that a 500G hard drive. A beginner not doing many photos, downloading/editing movies, installing several virtual machines, or having the 1000CD-collection in lossless on the harddrive wont use this space and it may be more susceptible to movements and slower.
Yes, but in the case of not being checked he also could hand over weapons to possible terrorists inside the security zone and they could do the attack.
There is a difference between having to kill yourself to do the attack or smuggling in weapons for money.
a) changing the rate of a random process does not mean you make it non-random
b) decay properties may depend on temperature and pressure for certain decays, there seems a dispute about it (see http://www.technologyreview.com/blog/arxiv/24307/)
c) Still, without further information i have doubts about the Thorium-powered cars.
Science: Ouch. The MPG which you get out of Thorium does not depend on the efficiency of a gasoline-powered car.
It for sure can fix the problem that singles are better consumers.
Just sent one to everybody who owes more than one months salary to the the credit card companies.