Lets Encrypt verifies ownership of the domain. If you see the secured indicator in the browser, its a gaurantee that your actually talking to the server of the people who own that domain. So, if people watch out for the right domain as well as the secured indicator, it provides additional safety. So, people need to know the domains of critical sites they might use, and look carefully at that domain name. This is true as well, if there were no TLS being used. TLS provides additional gaurantees you really are talking to that domain and that no one is listening. Lets Encrypt makes things much more secure, rather than less security than before. However, certs with stronger vetting would verify ownership more of the domain a well as the certificate, maybe making sure that the domain is not hosting a malicious site that is spoofing a real bank or something.
There is a solution to this: have two grades of certificates, one with one star free certicates based on the Lets Encrypt model, for low risk sites and two stars for high risk.
Lets Encrypt, would not be an issue at all, furthermore, providing we do this: It might be a good idea, to have multiple security levels in the indicator, maybe one star for a Lets Encrypt type cert, maybe two stars for more intensive verification methods. this would allow the easy availability of Lets Encrypt to continue, but for banks etc to apply for the second star certificate for higher level of verification.
For many sites, like the personal website, Lets Encrypt is fine, without it those sites wouldnt encrypt anyway since its not worth the vast sums for a certificate from one of the commercial providers. For a bank, getting a cert with stronger vetting might make sense, and there is a better trade off for them to do it.
You could then train users to look for one star for low risk sites, two stars for ecommerce and banking stuff.
Linux could be great for older hardware, provided Linux would stop shooting itself in the foot by dropping support for older hardware to make sure that old hardware cannot be used with Linux. Like dropping XAA which made sure old video cards cannot work with Linux, and Wayland which is designed to make certain that only the latest and greatet $300 video cards from AMD or Intel run with Linux
These older computers would be perfect for Linux, if Linux developers would stop shooting themselves in the foot by making sure people with old hardware cannot use Linux, things like dropping XAA support to make sure older video cards will not work with Linux, and now the Wayland disaster, which is specifically designed to make Linux unuseable on older hardware and anything less, it seems, than the most recent $300 super duper Intel or AMD graphics adapters (lets not even go into the Nvidia driver disaster).
It is important to have independent review of what is going on in public schools. Parents have a right to know and a right to file a complaint. Quite frankly, climate change doesn't belong in schools. People can find out whatever they want to know on their own. It has no purpose, really, for helping students find employment. The only reason it is even there is for a political agenda. Climate change is heavily politicized and more about an agenda to reduce first world countries to third world countries and global wealth redistribution. Maybe climate change is contributed to by industrial activity. But, that doesnt change the fact that climate change treaties are wealth redistribution schemes designed to make the US uncompetitive and wreck the US economy and are exploiting the issue to push a clearly political social agenda .
I can more empathize with Evolution. But, this too is politicized, and often used to attack Christianity. The fact is, the Catholic Church has issued encyclicals that individual catholics can accept Evolution. Young earth creationism is not universal in Christianity in any way. Creation can be in the framework of the big bang having a divine origination and then evolution happening afterwards after the initial first cause. But this won't stop atheists from trying to lie and exploit it to push their atheistic ideologies.
Chrome had better under the hood technology, better written code, fewer memory leaks. Chrome had sandboxing long before Firefox did (it does not have it yet really). Firefox was too busy adding crap like Pocket than to care about the quality of the core product.
On the other hand, the chrome user interface is HORRIBLE. What Firefox should have done was keep its old UI and add sandboxing and fix the memory leaks and bugs. This would have differentiated itself in UI but would have matched Chrome in relaibility and security. Instead they ignored the need for sandboxing and copied what is bad about chrome, the UI,.
Some have switched to Firefox clones however these clones copy all of Firefox's underlying technical problems like lack of a sandboxing. Given what a mess the web is today and the danger of bugs in browser code, sandboxing is a MUST in any serious web browser. This means multiprocess so that the kernel attack surface can be reduced and customized for the browser sand box process. Another advantage of multiprocess is it can clear any memory leaks when a tab is closed without having to close other tabs. The memory usage is not really greater because of the use of shared libraries.
The problem with this thinking is sites which handle payment data and other sensitive data who are refusing to upgrade. By keeping it for low risk sites, we also keep it for high risk sites to abuse as well. We have to cut it off for all sites to stop the high risk ones from using it.
TLS creates the appearance of security but high risk sites can use broken old technology with TLS and give the appearance of security when the security is terribly broken, giving the user (and even ignorant and lazy site operators) the false assurance of security. It actually is even more true of site operators who think they have good security because they have TLS when they do not. There are still companies out there that think this way and have this cavalier atttitude about security.
Maybe the browsers should offer a period where there is a warning message and the user has to manually override the message to load the site as which is now done with invalid certs. This would create enough inconvenience for users that it will prod site operators to fix things.
Also you mention unencrypted connections: The day might be coming when browsers dump all unencrypted HTTP support, which would be a good thing. Things are headed that way, to give people no excuse to not do it by google making getting TLS certs free and easy. But the point is if TLS is being used with broken alogorthms it creates the false appearance of security
This is harmful to Linux, otherwise Microsoft would not be involved. Its not Linux at all, since you are just running some userland tools on Windows. Something that gives people a reason to not run the fully open source Linux kernel is not healthy for Linux, or open source. Microsofts hope with this is to starve the Linux kernel of userbase by giving people a reason to not install Linux, why install Linux when you can get the userland installed as an app on windows? None of the distros should cooperate with this. Instead, efforts should focus on funding efforts to get WINE to where it can run 99% of windows apps flawlessly.
systemd is actually far more modular and decentralized than the old event system and more customizable. The people who oppose it don't know what they are talking about and just oppose it as a knee jerk reaction because its new. Since systemd supports sysv init scripts, it has all of the functionality of sysv, it only adds additional functionality. So the anti-systemd mentality is not that they cannot use it the way they want, but they do not think that people should be allowed to use the additional functionality that systemd provides.
For instance, systemd is far more elegant if you need to be able to start service only when multiple other events have occured and multiple conditions have been met and provides a very elegant way to monitor and generate events in a standardized way. Its decentralized and loosely coupled because of the dbus oriented design. If you want to start a service when a user does an su, this becomes much easier with systemd.
You can write new daemons that monitor dbus that can be custom programmed however someone wants in any programming language to define when a service should be started. systemd has stock daemons that are controlled by the unit files, but you can also write init daemons in any programming language that have custom logic.
All of the disinformation against systemd is really destructive and damaging to Linux they misrepresent everything systemd does.
The fact is systemd is an enormous improvement that makes Linux far more flexible and easier to manage.
Much of what you say is naive because old versions of Windows or Linux are full of known security vulnerabilities. So, Windows 2000 may boot, so you say it works. But it is full of security holes that were patched ages ago in newer versions. So while it does work, its not the work/doesnt work binary test that is really the determiner for suitability, its the security holes that do not keep the software from working but are there silently waiting. Linux has advantages with being open source but dont fool yourself that you can run old versions of Linux and be safe, like Windows, you have to apply security patches.
I thought support for Windows 2000 ended years ago, so this is mind blowing because it is a known insecure configuration. How could you write a spec like that? No wonder we have security problems.
To be fair, Linux has many of these same problems, in particular, because newer versions break compatability with old hardware, which forces old versions of the OS to be used on the old hardware. For instance, this happened with X11 when they removed XAA which broke support for a vast array of older video cards. This disregard for backward compatability keeps people using old security hole filled versions of software. Many warned against removing XAA, but the lead developers basically dont give a damn about users. The lets "remove old cruft and destroy backwards compatability" people should also be ignored, since you end up creating compatability problems that keeps people using older insecure versions.
as others have said here, its not at all hard to learn the language and many of us have. With the unemployment problems we have with american tech workers and the unemployment problem we have in the country (unlike the official statistics, the real number is more like 10-15% because people who have given up are not counted), its hard to argue that you cannot develop and train workers to work on this technology.
About 90% of learning the job is learning the *application specific* layout of the program, learning a language is very minor to that in comparison. Once you learn each of the major common categories of languages, mainly procedural, relational, parsing, markup, learning new languages is easy, its not like learning a human language, since using programming languages you have the benefit of using language documentation as you go, rote memorization is unnecessary and actually a waste of time. No one memorizes every API, not unless one has savant capabilities. Learning a new computer language can take, a week or two, if that. I learned C# in a few days (as far as being able to read and write the core language). You use references for all of the APIs. People can be up and running with new languages in no time.
This idea "we cant find workers who have 5 years of experience with language X" is the line of middle managers who don't program themselves and dont understand any of this, and think its like a human language. Its a nonsense argument. We can train programmer for COBOL in a very short period of time.Learni
The phrase "deep space suits are no longer needed" seems to give a clue. Maybe not RIGHT NOW, but I am sure at some point, it could be useful, maybe they wanted to finish up the blueprints for the suit so that it would be ready when they need it?
This article is fake news, Solar and wind are not cheap nor can they replace coal. They do not provide a base load. COal is cheap compared to solar and wind, is more abundant, does provide base load and can provide far more energy than solar or wind. Solar and wind cannot provide more than small fraction of coal. Scarcity produces higher prices, ergo, it is not cheap. It has low energy density as well, hence you can generate the same amount of energy with far smaller coal power plants, the equivalent solar and wind would involve massive infrastructure.
The only reason coal has declines is because of suppressive regulations. If the regulations are removed, then coal will become much more affordable and win in the market. Solar and wind cannot win in the market, because they are expensive.
that solar is environmentally friendly is also a myth. The massive amount of used solar panels is a huge environmental disaster in the making and the materials that they are made from are very rare, making photovoltaic nonsustainable. Due to low energy density of wind, there also exists massive material usage due to the large number of wind generators.
I agree with this. The "x11 is bloated" nonsense came from a book in the 1980s when computers had 2 MB of RAM. Its a myth because its far more efficient than Windows 10. The 1980s era X11 myth is long outdated and has no relevance in modern context.
What Wayland is supposed to do could have been done with X extension, mainly, what would be needed as far as I know is a way for X apps to be able to synchronize with the refresh rate of the display so it can draw a frame and have it ready for the next refresh, by being notified of a redraw deadline through an X extension for this purpose. Another thing is a buffer swapping feature that allows an application when it has finished drawing a frame allowing it to tell the window system the frame is ready. If it blew the refresh deadline, the window system will use the last complete frame from a previous refresh cycle and the new frame will be used for the next refresh. This prevents window tearing and so on that has been i suppose the big reason for Wayland. All we really needed was this refresh timing and deadline information to be made available to apps, the deadline is set some time before the actual screen refresh to give time for the compositor to combine the apps frames into a single screen frame, and a facility for apps to use a new pixmap into the refresh buffer. You also need an extension for the compositor process for it to get the frames from all the apps so it can composite them all together into a single frame for for the video cards output.
It should be noted as far as I am aware what Wayland does regarding direct rendering can already happen with DRI on the X server, your application has the video driver built into it and basically sends drawing commands directly to the GPU. This already happens with DRI on X. Yes, it can be dangerous, which is why there should be an easily accessible option to turn it off and send your openGL commands via GLX over X protocol to the X server which can then send them on to the GPU.
its been discussed before, every myth about systemd has been debunked: http://0pointer.de/blog/projects/the-biggest-myths.html. Since you can still use SysV init with systemd, there really is nothing for you to complain about because you can use sysv init type startup for your services if thats what you want.
systemd is a major improvement over what we had before, more modular, easier to read configuration, more flexible.
First of all, most distros have always had the same window system, X Windows. The reason for this is that since all applications and window managers which are GUI, have to talk to the WIndow System, its important to have standardization around the same API. Otherwise you end up with a MESS of an app that works on one distro not being able to run on another distro or having to run 10 different windowing systems, because each application ends up being tied down to one or the other. You also have to have video hardware drivers and those have to plugin to the window system as well. If we are going to change the core window system, all of the distros had better agree to it or else we will end up with a fractured ecosystem like above. Now, because of X's design of leaving look and feel to the Window Manager, you can completely change the look of the user interface by changing the window manager, which does not affect applications. This is why you can use the same apps regardless of what WM you use. Wayland should and will continue this philosophy.
All of what I said also applies to the sound server, as well, so it was important to standardize around pulseaudio if we are going to have a sound server, which is a good idea. The alternative to a sound server would be to incorporate that kind of functionality into the kernel, its better to have it in a user process rather than to add further complicated code to the kernel, as with X.
As for systemd, rather than to rehash all that here: please read this: http://0pointer.de/blog/projects/the-biggest-myths.html. Basically, systemd is a big improvement over what we had before and the criticisms are mostly myths.
For your reference: http://0pointer.de/blog/projects/the-biggest-myths.html I think systemd is a benefit, and was a good decision to include it as it standardizes on what the other distros are also using. A declarative style event driven startup is something that Ubuntu has long had with Upstart, so its nothing knew to Ubuntu.
I never really liked startup scripts. Basically, you ended up with dense, difficult to read scripts that reinvented the wheel for every service. Every script had to have code for monitoring PIDs, killing the process, restarting the process, etc. And the shell script is just not very efficient for this.
The declarative style of systemd makes far more sense. Ive helped many users who had questions like, how do I start a service and have it restarted automatically if it quits? Its a convoluted mess of monitoring PIDs and so on with shell script. In systemd, it was a one liner.
People who say that systemd is harder to use, you cant be serious. I mean, you have to be being facetious. The declarative unit files in systemd are far simpler than shell script. Most shell scripts I have seen are a horror to read.
Another lie about systemd is that its monolithic. Actually, its more modular than the old init system. It consists over 50 binaries, you can swap out parts of the system, because the system is based on a bus based designed. You can have your own init daemon watch DBUS for an event that you want to respond to and start your service after another kernel or userspace generated event, and announce events to the DBUS. So a completely modular architecture where you can write daemons to watch for and response to any event on the system.
Another lie is it takes away your ability to use SysV init., You are free to use SysV init files and shell scripts if you need to. My experience is the declarative format takes care of 99% of use cases with with 1/10th the code in a clearer style, but for those other 1% its still possible to use shell scripts.
The noise in opposition to systemd is basically FUD nonsense. I cant understand it. Its open source, its modular, it does everything the old Init system did allowing you to use sys V init, it only adds flexibility. So basically you are arguing that people should not be alllowed to use the functionality and flexibility it offers, because it doesnt actually remove any features or backwards compatability.
Never had any problem with systemd preventing bootup. Are you sure its systemd? I disabled graphical login on systemd systems on some computers and it tends to work fine, with one minor issue, some times you need to ctrl+alt+f1 to a command prompt. It looks just like a minor kernel isue or something. Ive added my own jobs to systemd with no problems. Overall systemd is an improvement, simpler declarative unit files, you can still use shell scripts if you want. A more modular architecture.
If you think that muslim radicals coming into the country is good for the country, if you think that mexican drug gangs and people flooding across the border to steal jobs from Americans is a good thing, if you think that the US is a terrible country and that 50 years ago when we were putting people on the moon, it was an awful country, and we need to throw that america away, then and we need to let people who destroyed their own countries like Mexicans and Muslims to come in and take it over, then you obviously will not like Trump.
Youve got everything backwards. the left concocted the absurd story to try to hide the fact the DNC is on the side of Islamic foreign states and radicals and that Hillary took loads of money from Islamist states where women are treated like dogs, and Obamas 20 scandals like using the IRS to go after his enemies, and the scandals uncovered by the emails (which did not come from Russia). Rice and Obama were desperate to find distraction so they were desperate enough so they broke the law to try to get something on Trump. They also cannot accept that they lost the election as they view themselves beyond reproach, when they break the law it is justified for the noble cause of globalism and their views that the US is an evil empire, and if they lose, it must be because of the Russians rather than the people rejecting their obviously morally superior views about what a horrible country the US is
One could use something like RBAC to give interpreter just the permissions they need, something like AppArmor, AppArmor or maybe some kind of solution could probably lock the interpreter out of trying to read a file from the users home directory. Part of the problem is the same file access calls are used by python to both access data it needs and to access the script to run. The interpreter may need to access some data out of the home directory. An interpreter based policy seems to be one of the few ways the problem can be sealed, to tell the interpreter to not execute files in the home directory. Otherwise, the user can be warned before a user directory file is accessed, or a runtime RBAC profile could be generated with access just to the user directory data file the interpreter will need. Unfortunately none of these are really perfect.
Step one would be to disallow any execution of files in the user writeable directories. But this does not fix the problem of the interpreter. One way might be to develop a RBAC profile or a program with an interpreter like Word, allowing it some access to configuration values it needs, but requiring user confirmation before any other file access, or restricting file access to a certain directory. The problem is differentiating between good accesses such as to a document the User wants to load, and malicious accesses. These problems can also be solved in Word itself by running all scripts in both an interpreter security profile and in a seperate process controlled by OS level RBAC. But with Word, you cant trust it to get this right or to do it at all. Unfortunately warning a user before a file is accessed by Word is imperfect since users tend to ignore such warnings. Running seperate instances of word in each their own sandbox which gives it access to just one document file is another solution to this.
Slashdot Mirror
Lets Encrypt verifies ownership of the domain. If you see the secured indicator in the browser, its a gaurantee that your actually talking to the server of the people who own that domain. So, if people watch out for the right domain as well as the secured indicator, it provides additional safety. So, people need to know the domains of critical sites they might use, and look carefully at that domain name. This is true as well, if there were no TLS being used. TLS provides additional gaurantees you really are talking to that domain and that no one is listening. Lets Encrypt makes things much more secure, rather than less security than before. However, certs with stronger vetting would verify ownership more of the domain a well as the certificate, maybe making sure that the domain is not hosting a malicious site that is spoofing a real bank or something.
There is a solution to this: have two grades of certificates, one with one star free certicates based on the Lets Encrypt model, for low risk sites and two stars for high risk.
Lets Encrypt, would not be an issue at all, furthermore, providing we do this: It might be a good idea, to have multiple security levels in the indicator, maybe one star for a Lets Encrypt type cert, maybe two stars for more intensive verification methods. this would allow the easy availability of Lets Encrypt to continue, but for banks etc to apply for the second star certificate for higher level of verification.
For many sites, like the personal website, Lets Encrypt is fine, without it those sites wouldnt encrypt anyway since its not worth the vast sums for a certificate from one of the commercial providers. For a bank, getting a cert with stronger vetting might make sense, and there is a better trade off for them to do it.
You could then train users to look for one star for low risk sites, two stars for ecommerce and banking stuff.
Linux could be great for older hardware, provided Linux would stop shooting itself in the foot by dropping support for older hardware to make sure that old hardware cannot be used with Linux. Like dropping XAA which made sure old video cards cannot work with Linux, and Wayland which is designed to make certain that only the latest and greatet $300 video cards from AMD or Intel run with Linux
These older computers would be perfect for Linux, if Linux developers would stop shooting themselves in the foot by making sure people with old hardware cannot use Linux, things like dropping XAA support to make sure older video cards will not work with Linux, and now the Wayland disaster, which is specifically designed to make Linux unuseable on older hardware and anything less, it seems, than the most recent $300 super duper Intel or AMD graphics adapters (lets not even go into the Nvidia driver disaster).
The GPL is reasonable, You want to use someone elses code you should give back the improvements you make. I dont see anything wrong with that.
I completely disagree. Situations like Grsecurity make me glad it is written the way it is.
It is important to have independent review of what is going on in public schools. Parents have a right to know and a right to file a complaint. Quite frankly, climate change doesn't belong in schools. People can find out whatever they want to know on their own. It has no purpose, really, for helping students find employment. The only reason it is even there is for a political agenda. Climate change is heavily politicized and more about an agenda to reduce first world countries to third world countries and global wealth redistribution. Maybe climate change is contributed to by industrial activity. But, that doesnt change the fact that climate change treaties are wealth redistribution schemes designed to make the US uncompetitive and wreck the US economy and are exploiting the issue to push a clearly political social agenda .
I can more empathize with Evolution. But, this too is politicized, and often used to attack Christianity. The fact is, the Catholic Church has issued encyclicals that individual catholics can accept Evolution. Young earth creationism is not universal in Christianity in any way. Creation can be in the framework of the big bang having a divine origination and then evolution happening afterwards after the initial first cause. But this won't stop atheists from trying to lie and exploit it to push their atheistic ideologies.
Chrome had better under the hood technology, better written code, fewer memory leaks. Chrome had sandboxing long before Firefox did (it does not have it yet really). Firefox was too busy adding crap like Pocket than to care about the quality of the core product.
On the other hand, the chrome user interface is HORRIBLE. What Firefox should have done was keep its old UI and add sandboxing and fix the memory leaks and bugs. This would have differentiated itself in UI but would have matched Chrome in relaibility and security. Instead they ignored the need for sandboxing and copied what is bad about chrome, the UI,.
Some have switched to Firefox clones however these clones copy all of Firefox's underlying technical problems like lack of a sandboxing. Given what a mess the web is today and the danger of bugs in browser code, sandboxing is a MUST in any serious web browser. This means multiprocess so that the kernel attack surface can be reduced and customized for the browser sand box process. Another advantage of multiprocess is it can clear any memory leaks when a tab is closed without having to close other tabs. The memory usage is not really greater because of the use of shared libraries.
The problem with this thinking is sites which handle payment data and other sensitive data who are refusing to upgrade. By keeping it for low risk sites, we also keep it for high risk sites to abuse as well. We have to cut it off for all sites to stop the high risk ones from using it.
TLS creates the appearance of security but high risk sites can use broken old technology with TLS and give the appearance of security when the security is terribly broken, giving the user (and even ignorant and lazy site operators) the false assurance of security. It actually is even more true of site operators who think they have good security because they have TLS when they do not. There are still companies out there that think this way and have this cavalier atttitude about security.
Maybe the browsers should offer a period where there is a warning message and the user has to manually override the message to load the site as which is now done with invalid certs. This would create enough inconvenience for users that it will prod site operators to fix things.
Also you mention unencrypted connections: The day might be coming when browsers dump all unencrypted HTTP support, which would be a good thing. Things are headed that way, to give people no excuse to not do it by google making getting TLS certs free and easy. But the point is if TLS is being used with broken alogorthms it creates the false appearance of security
This is harmful to Linux, otherwise Microsoft would not be involved. Its not Linux at all, since you are just running some userland tools on Windows. Something that gives people a reason to not run the fully open source Linux kernel is not healthy for Linux, or open source. Microsofts hope with this is to starve the Linux kernel of userbase by giving people a reason to not install Linux, why install Linux when you can get the userland installed as an app on windows? None of the distros should cooperate with this. Instead, efforts should focus on funding efforts to get WINE to where it can run 99% of windows apps flawlessly.
systemd is actually far more modular and decentralized than the old event system and more customizable. The people who oppose it don't know what they are talking about and just oppose it as a knee jerk reaction because its new. Since systemd supports sysv init scripts, it has all of the functionality of sysv, it only adds additional functionality. So the anti-systemd mentality is not that they cannot use it the way they want, but they do not think that people should be allowed to use the additional functionality that systemd provides.
For instance, systemd is far more elegant if you need to be able to start service only when multiple other events have occured and multiple conditions have been met and provides a very elegant way to monitor and generate events in a standardized way. Its decentralized and loosely coupled because of the dbus oriented design. If you want to start a service when a user does an su, this becomes much easier with systemd.
You can write new daemons that monitor dbus that can be custom programmed however someone wants in any programming language to define when a service should be started. systemd has stock daemons that are controlled by the unit files, but you can also write init daemons in any programming language that have custom logic.
All of the disinformation against systemd is really destructive and damaging to Linux they misrepresent everything systemd does.
The fact is systemd is an enormous improvement that makes Linux far more flexible and easier to manage.
Much of what you say is naive because old versions of Windows or Linux are full of known security vulnerabilities. So, Windows 2000 may boot, so you say it works. But it is full of security holes that were patched ages ago in newer versions. So while it does work, its not the work/doesnt work binary test that is really the determiner for suitability, its the security holes that do not keep the software from working but are there silently waiting. Linux has advantages with being open source but dont fool yourself that you can run old versions of Linux and be safe, like Windows, you have to apply security patches.
I thought support for Windows 2000 ended years ago, so this is mind blowing because it is a known insecure configuration. How could you write a spec like that? No wonder we have security problems.
To be fair, Linux has many of these same problems, in particular, because newer versions break compatability with old hardware, which forces old versions of the OS to be used on the old hardware. For instance, this happened with X11 when they removed XAA which broke support for a vast array of older video cards. This disregard for backward compatability keeps people using old security hole filled versions of software. Many warned against removing XAA, but the lead developers basically dont give a damn about users. The lets "remove old cruft and destroy backwards compatability" people should also be ignored, since you end up creating compatability problems that keeps people using older insecure versions.
as others have said here, its not at all hard to learn the language and many of us have. With the unemployment problems we have with american tech workers and the unemployment problem we have in the country (unlike the official statistics, the real number is more like 10-15% because people who have given up are not counted), its hard to argue that you cannot develop and train workers to work on this technology.
About 90% of learning the job is learning the *application specific* layout of the program, learning a language is very minor to that in comparison. Once you learn each of the major common categories of languages, mainly procedural, relational, parsing, markup, learning new languages is easy, its not like learning a human language, since using programming languages you have the benefit of using language documentation as you go, rote memorization is unnecessary and actually a waste of time. No one memorizes every API, not unless one has savant capabilities. Learning a new computer language can take, a week or two, if that. I learned C# in a few days (as far as being able to read and write the core language). You use references for all of the APIs. People can be up and running with new languages in no time.
This idea "we cant find workers who have 5 years of experience with language X" is the line of middle managers who don't program themselves and dont understand any of this, and think its like a human language. Its a nonsense argument. We can train programmer for COBOL in a very short period of time.Learni
The phrase "deep space suits are no longer needed" seems to give a clue. Maybe not RIGHT NOW, but I am sure at some point, it could be useful, maybe they wanted to finish up the blueprints for the suit so that it would be ready when they need it?
This article is fake news, Solar and wind are not cheap nor can they replace coal. They do not provide a base load. COal is cheap compared to solar and wind, is more abundant, does provide base load and can provide far more energy than solar or wind. Solar and wind cannot provide more than small fraction of coal. Scarcity produces higher prices, ergo, it is not cheap. It has low energy density as well, hence you can generate the same amount of energy with far smaller coal power plants, the equivalent solar and wind would involve massive infrastructure.
The only reason coal has declines is because of suppressive regulations. If the regulations are removed, then coal will become much more affordable and win in the market. Solar and wind cannot win in the market, because they are expensive.
that solar is environmentally friendly is also a myth. The massive amount of used solar panels is a huge environmental disaster in the making and the materials that they are made from are very rare, making photovoltaic nonsustainable. Due to low energy density of wind, there also exists massive material usage due to the large number of wind generators.
I agree with this. The "x11 is bloated" nonsense came from a book in the 1980s when computers had 2 MB of RAM. Its a myth because its far more efficient than Windows 10. The 1980s era X11 myth is long outdated and has no relevance in modern context.
What Wayland is supposed to do could have been done with X extension, mainly, what would be needed as far as I know is a way for X apps to be able to synchronize with the refresh rate of the display so it can draw a frame and have it ready for the next refresh, by being notified of a redraw deadline through an X extension for this purpose. Another thing is a buffer swapping feature that allows an application when it has finished drawing a frame allowing it to tell the window system the frame is ready. If it blew the refresh deadline, the window system will use the last complete frame from a previous refresh cycle and the new frame will be used for the next refresh. This prevents window tearing and so on that has been i suppose the big reason for Wayland. All we really needed was this refresh timing and deadline information to be made available to apps, the deadline is set some time before the actual screen refresh to give time for the compositor to combine the apps frames into a single screen frame, and a facility for apps to use a new pixmap into the refresh buffer. You also need an extension for the compositor process for it to get the frames from all the apps so it can composite them all together into a single frame for for the video cards output.
It should be noted as far as I am aware what Wayland does regarding direct rendering can already happen with DRI on the X server, your application has the video driver built into it and basically sends drawing commands directly to the GPU. This already happens with DRI on X. Yes, it can be dangerous, which is why there should be an easily accessible option to turn it off and send your openGL commands via GLX over X protocol to the X server which can then send them on to the GPU.
its been discussed before, every myth about systemd has been debunked: http://0pointer.de/blog/projects/the-biggest-myths.html. Since you can still use SysV init with systemd, there really is nothing for you to complain about because you can use sysv init type startup for your services if thats what you want.
systemd is a major improvement over what we had before, more modular, easier to read configuration, more flexible.
First of all, most distros have always had the same window system, X Windows. The reason for this is that since all applications and window managers which are GUI, have to talk to the WIndow System, its important to have standardization around the same API. Otherwise you end up with a MESS of an app that works on one distro not being able to run on another distro or having to run 10 different windowing systems, because each application ends up being tied down to one or the other. You also have to have video hardware drivers and those have to plugin to the window system as well. If we are going to change the core window system, all of the distros had better agree to it or else we will end up with a fractured ecosystem like above. Now, because of X's design of leaving look and feel to the Window Manager, you can completely change the look of the user interface by changing the window manager, which does not affect applications. This is why you can use the same apps regardless of what WM you use. Wayland should and will continue this philosophy.
All of what I said also applies to the sound server, as well, so it was important to standardize around pulseaudio if we are going to have a sound server, which is a good idea. The alternative to a sound server would be to incorporate that kind of functionality into the kernel, its better to have it in a user process rather than to add further complicated code to the kernel, as with X.
As for systemd, rather than to rehash all that here: please read this: http://0pointer.de/blog/projects/the-biggest-myths.html. Basically, systemd is a big improvement over what we had before and the criticisms are mostly myths.
For your reference: http://0pointer.de/blog/projects/the-biggest-myths.html
I think systemd is a benefit, and was a good decision to include it as it standardizes on what the other distros are also using. A declarative style event driven startup is something that Ubuntu has long had with Upstart, so its nothing knew to Ubuntu.
I never really liked startup scripts. Basically, you ended up with dense, difficult to read scripts that reinvented the wheel for every service. Every script had to have code for monitoring PIDs, killing the process, restarting the process, etc. And the shell script is just not very efficient for this.
The declarative style of systemd makes far more sense. Ive helped many users who had questions like, how do I start a service and have it restarted automatically if it quits? Its a convoluted mess of monitoring PIDs and so on with shell script. In systemd, it was a one liner.
People who say that systemd is harder to use, you cant be serious. I mean, you have to be being facetious. The declarative unit files in systemd are far simpler than shell script. Most shell scripts I have seen are a horror to read.
Another lie about systemd is that its monolithic. Actually, its more modular than the old init system. It consists over 50 binaries, you can swap out parts of the system, because the system is based on a bus based designed. You can have your own init daemon watch DBUS for an event that you want to respond to and start your service after another kernel or userspace generated event, and announce events to the DBUS. So a completely modular architecture where you can write daemons to watch for and response to any event on the system.
Another lie is it takes away your ability to use SysV init., You are free to use SysV init files and shell scripts if you need to. My experience is the declarative format takes care of 99% of use cases with with 1/10th the code in a clearer style, but for those other 1% its still possible to use shell scripts.
The noise in opposition to systemd is basically FUD nonsense. I cant understand it. Its open source, its modular, it does everything the old Init system did allowing you to use sys V init, it only adds flexibility. So basically you are arguing that people should not be alllowed to use the functionality and flexibility it offers, because it doesnt actually remove any features or backwards compatability.
Never had any problem with systemd preventing bootup. Are you sure its systemd? I disabled graphical login on systemd systems on some computers and it tends to work fine, with one minor issue, some times you need to ctrl+alt+f1 to a command prompt. It looks just like a minor kernel isue or something. Ive added my own jobs to systemd with no problems. Overall systemd is an improvement, simpler declarative unit files, you can still use shell scripts if you want. A more modular architecture.
If you think that muslim radicals coming into the country is good for the country, if you think that mexican drug gangs and people flooding across the border to steal jobs from Americans is a good thing, if you think that the US is a terrible country and that 50 years ago when we were putting people on the moon, it was an awful country, and we need to throw that america away, then and we need to let people who destroyed their own countries like Mexicans and Muslims to come in and take it over, then you obviously will not like Trump.
Youve got everything backwards. the left concocted the absurd story to try to hide the fact the DNC is on the side of Islamic foreign states and radicals and that Hillary took loads of money from Islamist states where women are treated like dogs, and Obamas 20 scandals like using the IRS to go after his enemies, and the scandals uncovered by the emails (which did not come from Russia). Rice and Obama were desperate to find distraction so they were desperate enough so they broke the law to try to get something on Trump. They also cannot accept that they lost the election as they view themselves beyond reproach, when they break the law it is justified for the noble cause of globalism and their views that the US is an evil empire, and if they lose, it must be because of the Russians rather than the people rejecting their obviously morally superior views about what a horrible country the US is
One could use something like RBAC to give interpreter just the permissions they need, something like AppArmor, AppArmor or maybe some kind of solution could probably lock the interpreter out of trying to read a file from the users home directory. Part of the problem is the same file access calls are used by python to both access data it needs and to access the script to run. The interpreter may need to access some data out of the home directory. An interpreter based policy seems to be one of the few ways the problem can be sealed, to tell the interpreter to not execute files in the home directory. Otherwise, the user can be warned before a user directory file is accessed, or a runtime RBAC profile could be generated with access just to the user directory data file the interpreter will need. Unfortunately none of these are really perfect.
Step one would be to disallow any execution of files in the user writeable directories. But this does not fix the problem of the interpreter. One way might be to develop a RBAC profile or a program with an interpreter like Word, allowing it some access to configuration values it needs, but requiring user confirmation before any other file access, or restricting file access to a certain directory. The problem is differentiating between good accesses such as to a document the User wants to load, and malicious accesses. These problems can also be solved in Word itself by running all scripts in both an interpreter security profile and in a seperate process controlled by OS level RBAC. But with Word, you cant trust it to get this right or to do it at all. Unfortunately warning a user before a file is accessed by Word is imperfect since users tend to ignore such warnings. Running seperate instances of word in each their own sandbox which gives it access to just one document file is another solution to this.