Too many frameworks... that's a good one. You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.
I guess I know what is really wrong with the industry: developers that think they can create their own framework, replacing several dozen man years of coding, debugging and testing in just a few days -- and then having the arrogance to think it will contain less vulnerabilities right from the get go then an established framework used by millions.
Yes, and what is the websites return on the currency mined? I'm gonna bet you that it is *FAR* less than that $0.003... it's like paying someone a $1000 to repair a $10 piece of clothing... stupidity.
So why not instead get the infra ready for micro payments?
You could pay them $0.003 directly, not waste electricity (which is going to be a huge problem if this becomes popular) and the website would have a *FAR* better return... of course, you would see that $0.003 on your bank statement (or whatever) instead of it hiding in your electricity bill. That might be off putting for some.
Javascript mining is so inefficient that it is almost a crime to waste electricity in that fashion...
It wouldn't surprise if the return is less than 1% of the electricity costs involved... in other words, if you had paid the site directly (with a micropayment) they'd get an order of magnitude more value *AND* there would be no CPU time wasted...
I hate CPU consuming scripts that run all night just because they're open in a tab . Tab Suspend type tools help a bit, but I still often find that browser developers are doing a very crappy job from protecting us from scripts (or other browser processes) consuming CPU resources (even pages without miners often consume way too much CPU).
So, I've been working on a solution that puts this control back into the hands of the user instead of hoping browser makers will finally wake hope.... and it is quite simplistic.
It involves identifying the foreground window, the process that is associated with it, a small white list and some convenient kernel level process Suspend/Unsuspend functions which are lightweight enough to call in rapid succession.
Is your window not active? You get your process suspended for 0.099 seconds out of every 0.1 second, giving you just enough juice to process some events but not enough to make a noticeable peak in CPU use.
Normally you'd ask the task scheduler to not assign so much CPU to a process, but most Kernels only allow fiddling with the priority (or nice value) but don't allow setting a hard limit. By just suspending the entire process and monitoring the foreground window, you can achieve this transparently and without the user noticing.
Already have a proof of concept, I should polish it up and put it on github...
This sounds more like a lack of unit testing... or perhaps, if programmers discovered this hole in the spec during implementation (which they often do), being overruled by incompetent members of committee.
...all she had to do for facebook to make the connection is to bring her smartphone (signed in to her "normal" facebook account) to her sex work. Location then does the rest. If she had left her smartphone at home, this would not be possible.
No, the app on cell phone A notices you are at location X at a certain time (using location data) The same app (or from the same corporation) on cell phone B notices you near location X at almost the same time. A and B also happen to have a mutual friend C...
Chances are good that if A and B know C, and A and B were near each other that A and B might know each other as well...
genetically modified plants designed to take carbon out of circulation.
Seriously? All plants take carbon out of circulation. They're probably one of the key players in the cycles of ice ages we have on this planet.
- Ice caps recede, more room for plant life, less and less CO2 in the air as layers upon layers of dead soil stacks on top each other. - Less CO2 results in less greenhouse effect cooling the planet down... ice caps grow reinforcing the cooling by reflecting more heat and leaving less space for CO2 consuming life. - Things look stable for a few millenia (but they're not really) - CO2 is slowly building up as not all of it is taken from the air anymore. The temperatures slowly increase. - Increasing temperatures are reinforced by melting ice caps and permafrost thawing pumping even more CO2 in the air. Plants and other CO2 consuming live flourishes. - Things look stable for a few millenia - Repeat...
Yes dear, the heating is mostly natural. Donot believe what these so-called scientists and climate specialist say, as any child can deduce in 4 simple steps how this planet works without even needing special equipment or even measuring anything.
If only we *were* crawling up on one of those spikes as you say...
The problem is, we're not crawling up one of those spikes, we're rocketing up on one, with no sign that we are about to level off (ie, our speed is still increasing).
Changes in tenths of degrees normally take several millenia, but here we are measuring such changes in mere decades, or two orders of magnitude faster than anything we ever seen or measured before.
Scroll down to the bottom of this picture to see how amazing recent measurements really are: https://xkcd.com/1732/
Jeez, hire some real developers. I have no sympathy for companies that hire the cheapest monkeys they can find that can utter the required resume keywords in an intelligible way.
Hiring people with 10+ years of experience in multiple languages and systems, even though far more expensive will save money in the long run. The savings on maintenance, security and extensibility alone will easily pay itself back, not to mention they'll build better, more scalable solutions, and do it in less time and with less lines of code...
(Yes, I am a grumpy developer that went freelance because managers have no clue what the difference is between a fresh graduate and someone with 20 years of experience).
Almost every *real* security exploit out there in the wild is found in C/C++ code. Real exploits are privilege escalations resulting from poorly validated input resulting in buffer overflows.
In Java, sure, there might be an exploit in the application, but it will highly likely be limited to that application. You could maybe delete its data or grab some passwords, who cares, it at least can't affect anything else -- it's isolated. Good luck however finding a root exploit when talking to a Java app, no matter how poorly coded....and *if* you do find one, it is most likely in a dependency used (like a decompressor/image decoder or other library... written in, yes, C/C++)...
Every time I read something like this, I just can't help but think that Americans are primarily wage slaves. This can't happen in Europe. You can refuse, and they cannot fire you without several formal warnings (and a warning can't be "refuses to work 60 hours a week").
They simply cannot make you work 60 hours a week, and they have to *ask* you nicely if you want to work overtime (with extra pay) on the weekend or evenings.
They also cannot spy on you, expect replies to mail/SMS/whatsapp outside office hours, fire you without reason, etc. In Europe, your boss is just another person with a different role, not somebody that must be obeyed without question or face consequences.
Incorrect. What actually happens is that with safer languages, more people can write software and the *average* competency drops. It does not however affect the competency of already competent coders when they use more secure languages.
You'd think that be obvious, but please keep convincing yourself.
Just imagine where Python could have been if it had static typing and delimited blocks which are the main problems opposed developers have with it. It would not have reduced the language in usability much at all, and it would still be highly suitable for scripting tasks.
I think it could then have been a real contender in the language space and would have been far more widely adopted. It could have been the default language for Android for example.
C/C++ suffers from a complexity problem, which it needs to do low level stuff. Often this the result of just too many types, too many #ifdefs, just too many edge cases. However its static typing and the amount of errors it catches at compile time is something to be praised.
Python has much less types and does away with compiler directives, and is generally a bit more expressive. This removes a lot of complexity, but it is not perfect. It could have been statically typed as well, without losing much in expressiveness. It also introduced indentation equals blocks, which was a huge mistake, and again, it would not have been any less of a language if it had simply adopted curly brace syntax.
So yes, Python is probably better than C/C++ when it comes to preventing bugs, even though it introduces new classes of bugs. There are however languages that offer the best of Python and C/C++. It may be worth your time to look into those.
Or are you suggesting that the people that actually write in these loose languages "because it saves me typing 5 characters" actually will write documentation saying that said function is called at new years eve? And will spend time on proper architecture? Perhaps in your fantasy world they also wrote unit tests with 90+% coverage?
No. You get the code dumped in your lap, and you will be praising the gods if there's an old completely outdated Confluence site that describes what some junior on the team thought that the software is supposed to do.
If that code is Javascript, then you might as well throw it away and rewrite it, it will be faster. If that code is Java, you can make modifications and refactorings to it and be reasonably sure that you didn't break anything totally unrelated.
And I suspect there is no such law at all as it seems based on nothing.
Better languages do result in less bugs. They may open vectors for a different type of bug, but that does not mean they are as frequent or as dangerous.
Take memory management. One misstep and your program gets killed or crashes because it reads or writes from memory that does not belong to it. Very easy to do in some languages, while other languages completely eliminate this class of bugs. Of course poor memory management can then result in memory leaks, but it won't crash, and not all such problems become memory leaks.
Some languages also practically eliminate arbitrary code execution and injection attacks, making them inherently more secure, at the cost of having bounds checks compiled into your program. This again eliminates a whole class of problems and introduces no new problems (maybe performance problems, but those are not bugs).
Then there is code maintenance and refactoring, something which is near impossible with loose languages. This is often why is not even attempted, leaving your with a code base that, if not planned in excruciating detail, will wither away and die. Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility... I think it is because they all turn into unmaintainable pieces of spaghetti code that no sane programmer wants to keep working on for long.
But there is the old adage in statically typed compiled languages "Hey, my code compiles! Now I get to find out where all my bugs really are."
It happens often enough that people write hundreds of lines of new code in a compiled language and actually find it runs correctly the first time. Perhaps you haven't experienced it yet... I have on many occasions.
On site for the most part, although working one day remote a week is often an option. If you work only remote, you are competing with developers from countries where living expenses are low, wages are low and/or taxes are low or all three. You can't win that.
My situation applies to Europe, where everyone and his dog wants an App, a Website or whatever. I do freelance work there as it pays far better. In the US it seems to be the same (I haven't seen a company that isn't hiring devs), unfortunately going to US is not an option for me due to strict immigration policies.
The fault is with whoever built that software, then with whoever hired those people to build that software, followed by whoever decided to buy this software, followed by YOU who allowed this shit to be installed on their systems without proper auditing. Grow a backbone.
Slashdot Mirror
Too many frameworks... that's a good one. You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.
I guess I know what is really wrong with the industry: developers that think they can create their own framework, replacing several dozen man years of coding, debugging and testing in just a few days -- and then having the arrogance to think it will contain less vulnerabilities right from the get go then an established framework used by millions.
Unconditional and immediate forfeiture of $10000 to every customer who got their data stolen as a result of poor security practices.
Yes, and what is the websites return on the currency mined? I'm gonna bet you that it is *FAR* less than that $0.003... it's like paying someone a $1000 to repair a $10 piece of clothing... stupidity.
So why not instead get the infra ready for micro payments?
You could pay them $0.003 directly, not waste electricity (which is going to be a huge problem if this becomes popular) and the website would have a *FAR* better return... of course, you would see that $0.003 on your bank statement (or whatever) instead of it hiding in your electricity bill. That might be off putting for some.
One of the many holes in the advertising platforms, aka. browsers... the first hole is of course letting websites run arbitrary code.
Javascript mining is so inefficient that it is almost a crime to waste electricity in that fashion...
It wouldn't surprise if the return is less than 1% of the electricity costs involved... in other words, if you had paid the site directly (with a micropayment) they'd get an order of magnitude more value *AND* there would be no CPU time wasted...
I hate CPU consuming scripts that run all night just because they're open in a tab . Tab Suspend type tools help a bit, but I still often find that browser developers are doing a very crappy job from protecting us from scripts (or other browser processes) consuming CPU resources (even pages without miners often consume way too much CPU).
So, I've been working on a solution that puts this control back into the hands of the user instead of hoping browser makers will finally wake hope.... and it is quite simplistic.
It involves identifying the foreground window, the process that is associated with it, a small white list and some convenient kernel level process Suspend/Unsuspend functions which are lightweight enough to call in rapid succession.
Is your window not active? You get your process suspended for 0.099 seconds out of every 0.1 second, giving you just enough juice to process some events but not enough to make a noticeable peak in CPU use.
Normally you'd ask the task scheduler to not assign so much CPU to a process, but most Kernels only allow fiddling with the priority (or nice value) but don't allow setting a hard limit. By just suspending the entire process and monitoring the foreground window, you can achieve this transparently and without the user noticing.
Already have a proof of concept, I should polish it up and put it on github...
This sounds more like a lack of unit testing... or perhaps, if programmers discovered this hole in the spec during implementation (which they often do), being overruled by incompetent members of committee.
...all she had to do for facebook to make the connection is to bring her smartphone (signed in to her "normal" facebook account) to her sex work. Location then does the rest. If she had left her smartphone at home, this would not be possible.
No, the app on cell phone A notices you are at location X at a certain time (using location data) The same app (or from the same corporation) on cell phone B notices you near location X at almost the same time. A and B also happen to have a mutual friend C...
Chances are good that if A and B know C, and A and B were near each other that A and B might know each other as well...
Seriously? All plants take carbon out of circulation. They're probably one of the key players in the cycles of ice ages we have on this planet.
- Ice caps recede, more room for plant life, less and less CO2 in the air as layers upon layers of dead soil stacks on top each other.
- Less CO2 results in less greenhouse effect cooling the planet down... ice caps grow reinforcing the cooling by reflecting more heat and leaving less space for CO2 consuming life.
- Things look stable for a few millenia (but they're not really)
- CO2 is slowly building up as not all of it is taken from the air anymore. The temperatures slowly increase.
- Increasing temperatures are reinforced by melting ice caps and permafrost thawing pumping even more CO2 in the air. Plants and other CO2 consuming live flourishes.
- Things look stable for a few millenia
- Repeat...
Yes dear, the heating is mostly natural. Donot believe what these so-called scientists and climate specialist say, as any child can deduce in 4 simple steps how this planet works without even needing special equipment or even measuring anything.
If only we *were* crawling up on one of those spikes as you say...
The problem is, we're not crawling up one of those spikes, we're rocketing up on one, with no sign that we are about to level off (ie, our speed is still increasing).
Changes in tenths of degrees normally take several millenia, but here we are measuring such changes in mere decades, or two orders of magnitude faster than anything we ever seen or measured before.
Scroll down to the bottom of this picture to see how amazing recent measurements really are: https://xkcd.com/1732/
Root exploits are nasty because the program hacked isn't running as root...
If it only it was so easy to simply not run anyhing as root...
Jeez, hire some real developers. I have no sympathy for companies that hire the cheapest monkeys they can find that can utter the required resume keywords in an intelligible way.
Hiring people with 10+ years of experience in multiple languages and systems, even though far more expensive will save money in the long run. The savings on maintenance, security and extensibility alone will easily pay itself back, not to mention they'll build better, more scalable solutions, and do it in less time and with less lines of code...
(Yes, I am a grumpy developer that went freelance because managers have no clue what the difference is between a fresh graduate and someone with 20 years of experience).
Almost every *real* security exploit out there in the wild is found in C/C++ code. Real exploits are privilege escalations resulting from poorly validated input resulting in buffer overflows.
In Java, sure, there might be an exploit in the application, but it will highly likely be limited to that application. You could maybe delete its data or grab some passwords, who cares, it at least can't affect anything else -- it's isolated. Good luck however finding a root exploit when talking to a Java app, no matter how poorly coded. ...and *if* you do find one, it is most likely in a dependency used (like a decompressor/image decoder or other library... written in, yes, C/C++)...
Every time I read something like this, I just can't help but think that Americans are primarily wage slaves. This can't happen in Europe. You can refuse, and they cannot fire you without several formal warnings (and a warning can't be "refuses to work 60 hours a week").
They simply cannot make you work 60 hours a week, and they have to *ask* you nicely if you want to work overtime (with extra pay) on the weekend or evenings.
They also cannot spy on you, expect replies to mail/SMS/whatsapp outside office hours, fire you without reason, etc. In Europe, your boss is just another person with a different role, not somebody that must be obeyed without question or face consequences.
That combination is not rare at all. It is only rare at the top of companies, as most of those people have no clue about IT *or* what people need.
It's probably even possible to not buy that phone at all and get a different one!
Incorrect. What actually happens is that with safer languages, more people can write software and the *average* competency drops. It does not however affect the competency of already competent coders when they use more secure languages.
You'd think that be obvious, but please keep convincing yourself.
Just imagine where Python could have been if it had static typing and delimited blocks which are the main problems opposed developers have with it. It would not have reduced the language in usability much at all, and it would still be highly suitable for scripting tasks.
I think it could then have been a real contender in the language space and would have been far more widely adopted. It could have been the default language for Android for example.
C/C++ suffers from a complexity problem, which it needs to do low level stuff. Often this the result of just too many types, too many #ifdefs, just too many edge cases. However its static typing and the amount of errors it catches at compile time is something to be praised.
Python has much less types and does away with compiler directives, and is generally a bit more expressive. This removes a lot of complexity, but it is not perfect. It could have been statically typed as well, without losing much in expressiveness. It also introduced indentation equals blocks, which was a huge mistake, and again, it would not have been any less of a language if it had simply adopted curly brace syntax.
So yes, Python is probably better than C/C++ when it comes to preventing bugs, even though it introduces new classes of bugs. There are however languages that offer the best of Python and C/C++. It may be worth your time to look into those.
Yes, the language it was written in was broken.
Or are you suggesting that the people that actually write in these loose languages "because it saves me typing 5 characters" actually will write documentation saying that said function is called at new years eve? And will spend time on proper architecture? Perhaps in your fantasy world they also wrote unit tests with 90+% coverage?
No. You get the code dumped in your lap, and you will be praising the gods if there's an old completely outdated Confluence site that describes what some junior on the team thought that the software is supposed to do.
If that code is Javascript, then you might as well throw it away and rewrite it, it will be faster. If that code is Java, you can make modifications and refactorings to it and be reasonably sure that you didn't break anything totally unrelated.
And I suspect there is no such law at all as it seems based on nothing.
Better languages do result in less bugs. They may open vectors for a different type of bug, but that does not mean they are as frequent or as dangerous.
Take memory management. One misstep and your program gets killed or crashes because it reads or writes from memory that does not belong to it. Very easy to do in some languages, while other languages completely eliminate this class of bugs. Of course poor memory management can then result in memory leaks, but it won't crash, and not all such problems become memory leaks.
Some languages also practically eliminate arbitrary code execution and injection attacks, making them inherently more secure, at the cost of having bounds checks compiled into your program. This again eliminates a whole class of problems and introduces no new problems (maybe performance problems, but those are not bugs).
Then there is code maintenance and refactoring, something which is near impossible with loose languages. This is often why is not even attempted, leaving your with a code base that, if not planned in excruciating detail, will wither away and die. Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility... I think it is because they all turn into unmaintainable pieces of spaghetti code that no sane programmer wants to keep working on for long.
It happens often enough that people write hundreds of lines of new code in a compiled language and actually find it runs correctly the first time. Perhaps you haven't experienced it yet... I have on many occasions.
On site for the most part, although working one day remote a week is often an option. If you work only remote, you are competing with developers from countries where living expenses are low, wages are low and/or taxes are low or all three. You can't win that.
My situation applies to Europe, where everyone and his dog wants an App, a Website or whatever. I do freelance work there as it pays far better. In the US it seems to be the same (I haven't seen a company that isn't hiring devs), unfortunately going to US is not an option for me due to strict immigration policies.
The fault is with whoever built that software, then with whoever hired those people to build that software, followed by whoever decided to buy this software, followed by YOU who allowed this shit to be installed on their systems without proper auditing. Grow a backbone.