The best system i found are plain text files for the really important things, in a year/month/day directory structure. Store it locally on a usb stick and use an arbitray sync tool or version mangement to sync between your devices.
Searching these is easy.
Better nuke the reservoir form orbit, the only way to be sure.
I am lucky I grew up in the 80s I guess.
I dont the f**k care. If 4 developers who are probably not assigned on full time to this task taake only a week to give it a good start, then for sure a company could have taken the effort in the many years in which this library is in use.
I can assure you that predicting market scenarios is mor complicated that you make it sound.
For sure they can get the DoF right in 3D movies, why not?
Funny. I never suggested that i would use Java for this purpose, i just pointed out that i assume that the same level of coding tools exists for C (as you stated yourself).
Regarding the VM JIT vs. statically compiled Code + and big amount of interpreters: Yes, for high-security code i definitly prefer stattically compiled code. OTOH i point out that *most* of the JVM vulnerabilities were actually not in the low layer compilation but in the somehow weird assumption that security can be managed inside the same adress space by high-level language features (which implicitely assumes that libraries of arbitrry complexity with JNI code inside are all written perfect).
I cant talk for C, but in Java the tools which warn you about potentially dangerous constructs are great (e.g. Sonar). You can easily identify many *suspicous* contructs and change them to something more safe. 250 commits per week with 4 devs on a moderatly sized project do not see much to me, much at the "quality" and not the "quantity" side.
What annoys me is that - with all due respect - the companies which embed openssl in their products could have done a review of the code for quality. To me it seems that it's a fundamental library.
Yes, and if you buy consulting work based on a flat amount of money for a project assigning the right people to the right task is something the consulting company does for you. Because if they do this then will earn more money.
If i find a bug which is critical to my employer while being plaid by my employer, the first and only thing which is do is assess the impact to my emplyer, and identify the most important measures for the employers business.
IMHO they acted correctly: protect your own systems, and then the systems with the biggest impact.
I am working as a consultant.
My good advice to every customer is: dont buy consultant work as time and material. Buying as time and material puts the wrong incentives to everybody:
-Your own people will feel that they still can just use them as normal workers and keep all decisions (and thus responsibility) to themself
-The consultants dont care, since just doing what your own people tell them without thinking is what gets their monthly timesheets signed. If something goes wrong they can even sell more hours, not less
-The consulting company does not care (and rigthly so since that was not what you asked for) and will send you inexperiences junior consultants wherever possible.
-Coding quality has to be reviewd by your own people (or just accepted as it is)
-Your own people are usually vastly inferior at project management in comparison to the average senior consultant - in a non T&M contract the usual situation is that you get the things done in time or you will loose money.
Wow they just managed to create uncanny deep holes to fall into.
Chernobyl would not have been prevented by putting the reactor in water. It was the only accident which had a "nuclear power excursion" as the reason. TMI and Fukushima were a failure of the classical cooling.
In Chernobyl the operators ignored the normal precautions. They operated the fuel in a state where xenon (see http://hyperphysics.phy-astr.g...) was present. Due to this the system was far away from the assumed stable oprtion point assumed in the controls.
The power which you would have needed to dissipate at the event to cool the reactor would have been ong the order of 200GW. Normal heat transfer coefficients are on the order of 10s of KW/m^2/K if i assume that you allow 200K difference on the surface, you end up at an active cooling surface of 100000m^2, which just is not there, not even if you drop the reactor into water.
Lat me get this right (from their wiki page):
GNOME, as the lead organization, has been responsible for managing the finances for the entire effort. However, as the program grew, the processes did not keep up. The changes were not tracked effectively from the point when other organizations joined the OPW. This impacted not only our ability to manage the OPW administration, but also to keep up with the core financial tasks of the Foundation -- tasks which already needed the full attention of the Foundation's employees and the board.
So other organizations accepted liabilities which were automatically transferred to GNOME Foundation? or they plainly lost track? Or they did not caclulate before what limit for accepting students there is?
Or WHAT?
Did they - by spending money on a side track -fuck up an organization which should - given the situation about people not bein happy with they main project - focus on stakeholder management? I mean it's not like that job is not important for the FOSS community. And wo me it seems that the exeution of the job leaves some things to be desired.
The national security interest would be to patch the hole, not to leave it open. This hole was to easy to exploit, and supposedly enabled identity theft on a massive scale, even to vastly infereior intelligence services.
The comparison with the centrifuges in Iran is misleading. for that combination of attacks it is very hard even to find suitable experts to generate the code.
Remember to say hello to your bank teller.
