Some of the Mac laptops have the same issue. This was a few years back... They will drain the battery about 1-2% per hour if you use both CPU and GPU while plugged in. Apple wanted to not have huge bricks for power adapters. Meanwhile my Dell can run CPU, display, gpu, AND rapid charge the battery. But the 210w adapter is huge and the laptop and charger are over 10 pounds.
Given a lot of people in the office is switching to Mac, and weight is a primary concern, seems like a good trade-off. That said, I like not having to worry about the battery capacity and don't care about the weight.
I hated the tab look when it came out (see some of my earlier posts). I switched to the "light" theme and have gotten used to them since. Doesn't bug me now.
No, I haven't seen any problems like that. It really has been rock solid for me, although I'm not using Ars Technica forums. Slashdot has had no issues for me either.
That's interesting. I see a huge speed difference and stability improvement. I've had no failures of pages to render, which were frequent in 56.
But if Firefox ESR is working for you, stick with it. I hope that Mozilla realizes that they've cut out a lot of features and work to bring the most important ones back to extension authors, now that they have a good, solid base.
As a follow-up, I've been using this for a day now and it's quite fantastic. I've started to get used to the new tab look, and while I don't like it as much, it doesn't bug me as much.
The performance is just downright amazing. Firefox is BACK.
Seems like a worthwhile trade to me. The browser hasn't paused, hung up, or stopped operating yet this morning. I haven't had any tabs crash to a white screen, all of which happened in FF 56.
And none of my extensions are gone. All of the extensions I use have been implemented in FF57. I know others are pissed--and fully understand why--but I like the new version. A lot. Except for the tabs. Gah, those are so ugly.
I'm totally rooting for FireFox. I just saw the notification, downloaded it, and yes, the gaps were the first thing I noticed.
Gee whiz, give us a few days to drive it to comment on performance. Generally restarting a program improves its performance. But the out of box experience (gaps and tabs) was not pleasant. I've fixed the gaps based on brickhouse98's comment (thanks!), but the tab coloring SUCKS.
In 2 hours of usage, it seems much faster than the previous version, even though I had multi-threading enabled in the previous version. I like it a lot, and I agree that for Privacy, having FF around is key for us.
I'm rooting for FF, but I give honest reviews and speak truth. Ignoring problems with your own team is a primary cause of much of the world's trouble, especially in politics. I refuse to play THAT game.
IQ is a measure of general problem solving ability. Whether that theory holds or not, I fail to see how your example of shimmying relates to general IQ. Perhaps I was naive in assuming you were actually proposing such a position. I have never observed a correlation (through scientific study or personal experience) between problem solving and dancing skill. I'm not aware of anyone who's specifically interested in using dancing to measure problem solving, or even proposes that those two are related. It's not even clear that advanced mental prowess is a primary skill requirement of dancing. For this reason, I assumed your goal was to provide a strawman argument. In short, I don't believe that many IQ researchers would seriously posit that dancing significantly correlates with IQ, let alone that dancing could be used as a predictor. Can you cite anyone making such a claim?
Hopefully the above is a direct enough answer to your statement. If you wish to challenge IQ on its merits, you need to refute the position of its theory. "General intelligence" is about problem solving, not coordination, or possibly visual skills (as stated in the original article).
I can't speak to the level of flaws in the current IQ tests, but price is always a consideration. Welcome to engineering. That something needs to be affordable is a prime criterion in any product or process. We have limited resources and we must prioritize the best positive impact we can get with those resources.
IQ and Personality tests have in general been put together through running regressions through sets of questions. Correlations are seen between sets of questions, and then the groupings are labeled and additional information is drawn from them.
This is fairly mundane. It should be obvious to see that people who score highly on "I consider myself a creative person" would also score highly on "I come up with new ideas" and low on "I tend to only think inside the box". Once a lot of people take these tests, you can see patterns in the data and group the questions without knowing anything else about the data.
IQ tests, likewise, were developed in a similar fashion by Binet. He found which questions more advanced students did well on, and he was able to identify younger students that were likely to do well as they grew up. He called this an IQ test and used it to determine which students needed the most help in school. To me, this seems like a pretty noble goal--let's predict students that are likely to struggle so we can assist them and give them a good chance at success.
Many people since this time have tried to refine the IQ test, because it does have limits. Cultural bias is, for instance, a problem. But again, it's all based on the questions and groupings, and when you're dealing with data analysis, biases in the general population will be seen in the data results. Bias in the input data is the problem Google is dealing with right now, and it's why Google's AI thinks being gay is bad:
https://motherboard.vice.com/e...
So if you find a huge issue with IQ tests, I encourage you to take your time and energy to improve the IQ tests to reduce bias and improve the quality of the results. If we were to qualify students based on their ability to dance, this might be useful for Juilliard, but I suspect you'll find that dancing ability is not well correlated to most professions. You want to make sure people's abilities are well-matched to their job requirements--if your goal is a successful economy and satisfied employees, which is my goal. If your goal is to simply "level the playing field", well, then, by all means, change the qualifications for jobs to shimmying. But don't be surprised when your economy collapses and many people starve. It's been tried many, many times before and it doesn't work well. Read the Gulag Archipelago if you don't believe me.
I think IQ tests are not that big of a problem. Tons of studies and analysis show them to be great predictors of all sorts of things--overall life success, earnings potential, etc--and that makes them very useful. I say this as someone who doesn't really like school--never want to go back, despite having a very high IQ and doing very well in school. My high IQ helps me tremendously in my software development career, however, as I'm able to solve problems vastly more quickly than most of my peers. So I do believe the current IQ tests to be an imperfect but extremely useful tool for predicting success in a variety of ways, and their bad rap is mostly undeserved.
I know you said you just pulled that out of your ass, but you're actually correct. IQ does appear to have a basis in physiology. Peripheral nerve speed is strongly correlated to IQ. That's basically the robustness of the speed of connections between neurons as you stated. You can give someone a reflex test and fairly reliable judge their intelligence based on that alone. I shouldn't have to state that a correlation isn't perfect, and there are exceptions. I'm sure someone will come out with an anecdotal counterexample.
IQ is strongly correlated across most domains of what most people would call intelligence. In other words, someone who is good at problem solving in math is likely to be good at problem solving in language as well. There are exceptions, of course. but generally if a person has a low IQ, they will not be good at a variety of domains
A person with a high IQ will generally be good at most domains. At the higher end of the spectrum, more differentiation appears. That is you might see a math Savant who's just average in language but it's unusual to see a person who's low intelligence be spontaneously good at one of the domains.
The finding that vision is not correlated with IQ was actually quite novel.
If you want more information on intelligence, Jordan Peterson has a number of lectures on the matter on Youtube. It would be really good listening if you're interested in this topic.
Funny. I work in a shop of 50 java developers (some of which had other programming backgrounds, many of which did not), and they're all great developers and I'd love to work with any of them in any future job.
But yes, a solid background in assembly or C to understand what the processor is doing really helps.
This is not true. SHA2 is only ~15% slower than MD5 at verifying a hash for small data inputs (typical for password bruteforcing). Use bcrypt/scrypt instead.
DO NOT secure a password/cc/sensitive info DB with MD5 or SHA1/2/3.
If you're worried about offline attacks, you should use bcrypt.
To answer the GP's post:
1) MD5 is vulnerable to certain padding attacks. For instance, Microsoft had a cryptographically signed binary hacked by a dedicated attacker to hijack windows update. Basically, someone created an executable with a virus payload that resolved to the same MD5 signature as the original package. That's BAD.
https://www.theregister.co.uk/...
This means that, in certain cases, you CAN make MD5 secure by doing very special things around how MD5 is used. But you have to know exactly what you're doing and SHA2 is really better anyway. So just use SHA2...
2) SHA1 is has recently had vulnerabilities to the same types of usage. Do not use SHA1 or MD5 for cryptographically signing things. Keep in mind, it's still REALLY difficult to create a SHA1 collision, but engineers at Google did it.
https://thehackernews.com/2017...
3) SHA2/3 are still looking secure. It's reasonably expected that if you sign something with SHA2 or SHA3, that someone will not be able to create a different binary/payload as you can with SHA1/MD5.
4) NONE of the above should be used to secure a password/credit card/secure info database. MD5, SHA/1/2/3. For a password database, the worry is someone will hack the DB and extract the information. For this, you should use scrypt or bcrypt (possibly with a salt and/or pepper). This is because the hacker will have the information offline and plenty of time and resources to hack it. In this case, the attacker is trying to brute force the database (by trying every password), with a limited set of (likely) passwords.
For 1-3, you want something that can verify the hash as quickly as possible. For usecase #4, you want an algorithm that takes a long time to verify the hash. This is because a brute force's success rate is dependent on how fast you can try all of the possibilities. If you have 1000 possible passwords and each attempt takes 1ms, then you can try every possible password in 1 second. If each attempt takes 500ms, then this will take 500 seconds.
For this, scrypt/bcrypt has a difficulty algorithm that scales. You basically decide how hard it is to verify a password based on the computational resources at your disposal and how long it should take a user to login. In an application I work on, hash computation actually takes a majority of the login time for the application.
In short:
1) Use Sha2/3 to sign packages, binaries, or transmissions
2) Use scrypt or bcrypt to encrypt data against offline attacks. Pick a difficulty strength as high as you can tolerate.
3) Use MD5 or SHA1 only as a non-cryptographic checksum (did my file get corrupted by a bit flip?--not is someone attacking me)
4) If you use MD5 to sign packages, binaries or transmissions, cracking your encryption will be relatively easy.
5) If you use SHA1 to sign packages, binaries, or transmissions, cracking your encryption will be possible for dedicated hackers.
What I meant by "it's more portable" is that my code runs on any supported system without modifications or with extremely minor modifications.
What you're talking about I called "platform support", which I explicitly called out in my post. C wins against Java for platform support.
In general, C runs on far more platforms than Java code, but it takes more work to support each platform. It also depends on if you want or need to target small, embedded, or niche platforms. The main CPU architectures and OS's have good quality JVM's available.
Only speaking about server apps in Java... Swing/GUI/applets is a hot mess...
Java has very good backwards compatibility. We compile our app for Java 7 and run it with 7, 8 and 9. Very few bugs exist when we do a major upgrade... Typically 1-2. For minor versions within the same major release (updates as they're called in Java), we haven't seen a single backwards compatibility issue in probably 8 years.
Sounds like you're talking about very old versions of Java (version 4 and earlier), or GUI code, which does have these issues.
Easier? Probably, since you know c. For me, Java is definitely easier.
More portable? Doubtful. I work on an Enterprise app with millions of lines of code and the same Jar works fine with essentially no extra work on both the IBM JDK and Sun JDK on Windows, Linux, and HP-UX.
We encounter typically 1-2 issues a year that are OS or JDK dependent issues. This is
If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.
Sure, except in this case, it's not (primarily thanks to T-Mobile).
I might have agreed with you 4 years ago, but not anymore. I paid upfront for all phones on my Sprint account, and got a hefty discount on the monthly bill as a result. You can either get the (widely advertised) 2 year contract plans, or you can bring your own phone and get a discounted value plan. I signed up for a value plan which ended up about $15/line less than the contract plan, but I don't get discounted phones.
In short: You don't NEED a contract. You just need to save money and not take out invisible loans on discounted hardware.
Slashdot Mirror
Some of the Mac laptops have the same issue. This was a few years back... They will drain the battery about 1-2% per hour if you use both CPU and GPU while plugged in. Apple wanted to not have huge bricks for power adapters. Meanwhile my Dell can run CPU, display, gpu, AND rapid charge the battery. But the 210w adapter is huge and the laptop and charger are over 10 pounds.
Given a lot of people in the office is switching to Mac, and weight is a primary concern, seems like a good trade-off. That said, I like not having to worry about the battery capacity and don't care about the weight.
I hated the tab look when it came out (see some of my earlier posts). I switched to the "light" theme and have gotten used to them since. Doesn't bug me now.
No, I haven't seen any problems like that. It really has been rock solid for me, although I'm not using Ars Technica forums. Slashdot has had no issues for me either.
Love it. Fast and fixes rendering issues I had in FF 56.
That's interesting. I see a huge speed difference and stability improvement. I've had no failures of pages to render, which were frequent in 56.
But if Firefox ESR is working for you, stick with it. I hope that Mozilla realizes that they've cut out a lot of features and work to bring the most important ones back to extension authors, now that they have a good, solid base.
As a follow-up, I've been using this for a day now and it's quite fantastic. I've started to get used to the new tab look, and while I don't like it as much, it doesn't bug me as much.
The performance is just downright amazing. Firefox is BACK.
Seems like a worthwhile trade to me. The browser hasn't paused, hung up, or stopped operating yet this morning. I haven't had any tabs crash to a white screen, all of which happened in FF 56.
And none of my extensions are gone. All of the extensions I use have been implemented in FF57. I know others are pissed--and fully understand why--but I like the new version. A lot. Except for the tabs. Gah, those are so ugly.
Thank you!
I'm totally rooting for FireFox. I just saw the notification, downloaded it, and yes, the gaps were the first thing I noticed.
Gee whiz, give us a few days to drive it to comment on performance. Generally restarting a program improves its performance. But the out of box experience (gaps and tabs) was not pleasant. I've fixed the gaps based on brickhouse98's comment (thanks!), but the tab coloring SUCKS.
In 2 hours of usage, it seems much faster than the previous version, even though I had multi-threading enabled in the previous version. I like it a lot, and I agree that for Privacy, having FF around is key for us.
I'm rooting for FF, but I give honest reviews and speak truth. Ignoring problems with your own team is a primary cause of much of the world's trouble, especially in politics. I refuse to play THAT game.
IQ is a measure of general problem solving ability. Whether that theory holds or not, I fail to see how your example of shimmying relates to general IQ. Perhaps I was naive in assuming you were actually proposing such a position. I have never observed a correlation (through scientific study or personal experience) between problem solving and dancing skill. I'm not aware of anyone who's specifically interested in using dancing to measure problem solving, or even proposes that those two are related. It's not even clear that advanced mental prowess is a primary skill requirement of dancing. For this reason, I assumed your goal was to provide a strawman argument. In short, I don't believe that many IQ researchers would seriously posit that dancing significantly correlates with IQ, let alone that dancing could be used as a predictor. Can you cite anyone making such a claim?
Hopefully the above is a direct enough answer to your statement. If you wish to challenge IQ on its merits, you need to refute the position of its theory. "General intelligence" is about problem solving, not coordination, or possibly visual skills (as stated in the original article).
I can't speak to the level of flaws in the current IQ tests, but price is always a consideration. Welcome to engineering. That something needs to be affordable is a prime criterion in any product or process. We have limited resources and we must prioritize the best positive impact we can get with those resources.
Yes, I see the gaps too, and yes, I find the tabs far harder to read. The visual changes are... annoying.
IQ and Personality tests have in general been put together through running regressions through sets of questions. Correlations are seen between sets of questions, and then the groupings are labeled and additional information is drawn from them.
This is fairly mundane. It should be obvious to see that people who score highly on "I consider myself a creative person" would also score highly on "I come up with new ideas" and low on "I tend to only think inside the box". Once a lot of people take these tests, you can see patterns in the data and group the questions without knowing anything else about the data.
IQ tests, likewise, were developed in a similar fashion by Binet. He found which questions more advanced students did well on, and he was able to identify younger students that were likely to do well as they grew up. He called this an IQ test and used it to determine which students needed the most help in school. To me, this seems like a pretty noble goal--let's predict students that are likely to struggle so we can assist them and give them a good chance at success.
Many people since this time have tried to refine the IQ test, because it does have limits. Cultural bias is, for instance, a problem. But again, it's all based on the questions and groupings, and when you're dealing with data analysis, biases in the general population will be seen in the data results. Bias in the input data is the problem Google is dealing with right now, and it's why Google's AI thinks being gay is bad: https://motherboard.vice.com/e...
So if you find a huge issue with IQ tests, I encourage you to take your time and energy to improve the IQ tests to reduce bias and improve the quality of the results. If we were to qualify students based on their ability to dance, this might be useful for Juilliard, but I suspect you'll find that dancing ability is not well correlated to most professions. You want to make sure people's abilities are well-matched to their job requirements--if your goal is a successful economy and satisfied employees, which is my goal. If your goal is to simply "level the playing field", well, then, by all means, change the qualifications for jobs to shimmying. But don't be surprised when your economy collapses and many people starve. It's been tried many, many times before and it doesn't work well. Read the Gulag Archipelago if you don't believe me.
I think IQ tests are not that big of a problem. Tons of studies and analysis show them to be great predictors of all sorts of things--overall life success, earnings potential, etc--and that makes them very useful. I say this as someone who doesn't really like school--never want to go back, despite having a very high IQ and doing very well in school. My high IQ helps me tremendously in my software development career, however, as I'm able to solve problems vastly more quickly than most of my peers. So I do believe the current IQ tests to be an imperfect but extremely useful tool for predicting success in a variety of ways, and their bad rap is mostly undeserved.
I know you said you just pulled that out of your ass, but you're actually correct. IQ does appear to have a basis in physiology. Peripheral nerve speed is strongly correlated to IQ. That's basically the robustness of the speed of connections between neurons as you stated. You can give someone a reflex test and fairly reliable judge their intelligence based on that alone. I shouldn't have to state that a correlation isn't perfect, and there are exceptions. I'm sure someone will come out with an anecdotal counterexample.
IQ is strongly correlated across most domains of what most people would call intelligence. In other words, someone who is good at problem solving in math is likely to be good at problem solving in language as well. There are exceptions, of course. but generally if a person has a low IQ, they will not be good at a variety of domains A person with a high IQ will generally be good at most domains. At the higher end of the spectrum, more differentiation appears. That is you might see a math Savant who's just average in language but it's unusual to see a person who's low intelligence be spontaneously good at one of the domains.
The finding that vision is not correlated with IQ was actually quite novel.
If you want more information on intelligence, Jordan Peterson has a number of lectures on the matter on Youtube. It would be really good listening if you're interested in this topic.
I can only have it for one day? Not a problem!
"iPhone X dust. Don't breathe this!"
Funny. I work in a shop of 50 java developers (some of which had other programming backgrounds, many of which did not), and they're all great developers and I'd love to work with any of them in any future job.
But yes, a solid background in assembly or C to understand what the processor is doing really helps.
Dear heavens. MD5 and SHA2 are of equivalent difficulty to use in most cases. Just use SHA2 instead. It's safer and nearly as fast.
/rant
There's like--almost no reason--to implement new code with MD5--unless you're on small embedded platforms that don't support it or something.
This is not true. SHA2 is only ~15% slower than MD5 at verifying a hash for small data inputs (typical for password bruteforcing). Use bcrypt/scrypt instead.
DO NOT secure a password/cc/sensitive info DB with MD5 or SHA1/2/3.
See this:
http://automationrhapsody.com/...
And my post here:
https://developers.slashdot.or...
If you're worried about offline attacks, you should use bcrypt.
To answer the GP's post: 1) MD5 is vulnerable to certain padding attacks. For instance, Microsoft had a cryptographically signed binary hacked by a dedicated attacker to hijack windows update. Basically, someone created an executable with a virus payload that resolved to the same MD5 signature as the original package. That's BAD. https://www.theregister.co.uk/...
MD5 is vulnerable to what's called a "length extension attack": https://en.wikipedia.org/wiki/...
This means that, in certain cases, you CAN make MD5 secure by doing very special things around how MD5 is used. But you have to know exactly what you're doing and SHA2 is really better anyway. So just use SHA2...
2) SHA1 is has recently had vulnerabilities to the same types of usage. Do not use SHA1 or MD5 for cryptographically signing things. Keep in mind, it's still REALLY difficult to create a SHA1 collision, but engineers at Google did it. https://thehackernews.com/2017...
3) SHA2/3 are still looking secure. It's reasonably expected that if you sign something with SHA2 or SHA3, that someone will not be able to create a different binary/payload as you can with SHA1/MD5.
4) NONE of the above should be used to secure a password/credit card/secure info database. MD5, SHA/1/2/3. For a password database, the worry is someone will hack the DB and extract the information. For this, you should use scrypt or bcrypt (possibly with a salt and/or pepper). This is because the hacker will have the information offline and plenty of time and resources to hack it. In this case, the attacker is trying to brute force the database (by trying every password), with a limited set of (likely) passwords.
For 1-3, you want something that can verify the hash as quickly as possible. For usecase #4, you want an algorithm that takes a long time to verify the hash. This is because a brute force's success rate is dependent on how fast you can try all of the possibilities. If you have 1000 possible passwords and each attempt takes 1ms, then you can try every possible password in 1 second. If each attempt takes 500ms, then this will take 500 seconds.
For this, scrypt/bcrypt has a difficulty algorithm that scales. You basically decide how hard it is to verify a password based on the computational resources at your disposal and how long it should take a user to login. In an application I work on, hash computation actually takes a majority of the login time for the application.
In short:
1) Use Sha2/3 to sign packages, binaries, or transmissions
2) Use scrypt or bcrypt to encrypt data against offline attacks. Pick a difficulty strength as high as you can tolerate.
3) Use MD5 or SHA1 only as a non-cryptographic checksum (did my file get corrupted by a bit flip?--not is someone attacking me)
4) If you use MD5 to sign packages, binaries or transmissions, cracking your encryption will be relatively easy.
5) If you use SHA1 to sign packages, binaries, or transmissions, cracking your encryption will be possible for dedicated hackers.
Good points.
Agreed. I called that platform support. I admit my terminology was somewhat ambiguous.
See my comment here:
https://slashdot.org/comments....
What I meant by "it's more portable" is that my code runs on any supported system without modifications or with extremely minor modifications.
What you're talking about I called "platform support", which I explicitly called out in my post. C wins against Java for platform support.
In general, C runs on far more platforms than Java code, but it takes more work to support each platform. It also depends on if you want or need to target small, embedded, or niche platforms. The main CPU architectures and OS's have good quality JVM's available.
Only speaking about server apps in Java... Swing/GUI/applets is a hot mess...
Java has very good backwards compatibility. We compile our app for Java 7 and run it with 7, 8 and 9. Very few bugs exist when we do a major upgrade... Typically 1-2. For minor versions within the same major release (updates as they're called in Java), we haven't seen a single backwards compatibility issue in probably 8 years.
Sounds like you're talking about very old versions of Java (version 4 and earlier), or GUI code, which does have these issues.
Should have been "This is less than 1% of our development budget".
Java developer here...
Easier? Probably, since you know c. For me, Java is definitely easier.
More portable? Doubtful. I work on an Enterprise app with millions of lines of code and the same Jar works fine with essentially no extra work on both the IBM JDK and Sun JDK on Windows, Linux, and HP-UX.
We encounter typically 1-2 issues a year that are OS or JDK dependent issues. This is
If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.
Sure, except in this case, it's not (primarily thanks to T-Mobile).
I might have agreed with you 4 years ago, but not anymore. I paid upfront for all phones on my Sprint account, and got a hefty discount on the monthly bill as a result. You can either get the (widely advertised) 2 year contract plans, or you can bring your own phone and get a discounted value plan. I signed up for a value plan which ended up about $15/line less than the contract plan, but I don't get discounted phones.
In short: You don't NEED a contract. You just need to save money and not take out invisible loans on discounted hardware.