Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Learning new language can be done quickly (Score 1) 371

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

Comment Fake news (Score 2) 478

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.

Comment Re:But is Wayland better? (Score 2, Insightful) 227

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.

Comment Re:Well (Score 1, Flamebait) 227

its been discussed before, every myth about systemd has been debunked: 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.

Comment Re:So what makes Ubuntu different from Fedora? (Score 4, Interesting) 227

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: Basically, systemd is a big improvement over what we had before and the criticisms are mostly myths.

Comment Re:Elephant in the room (Score 0) 227

For your reference:
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.

Comment Re: Wonderful? (Score 2) 386

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.

Comment Re:Trump's wall is burning down, burning down... (Score 0, Flamebait) 396

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.

Comment Re:Well that's all interesting and good... (Score 0) 396

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

Comment Re:Devs (Score 1) 63

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.

Comment Re:Devs (Score 1) 63

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.

Comment Re:Devs (Score 1) 63

It should be pointed out x86-64 has security facilities that are equivalent to a harvard architecture, protection levels, setting pages with read/write/execute bits and so forth, as with the NX bit. The problem here is Word, and the security profiles at the OS level that allow scripts to access the filesystem. A harvard architecture would introduce inefficiencies in memory and bus utilization without giving you anything that you cant get with page tables and privilege levels on

Comment Re:Devs (Score 1) 63

The code should go into a sandbox, or not be run at all. A sandbox is an option both OS level, and the interpreter. Running code without that in a DOC file IS nuts. Reducing the kernel attack surface like Chrome has done is one tactic that can be used, using a controller/controllee sandbox. Its not rocket science. Its just plain incompetence to not do this.

Comment Re:Devs (Score 1) 63

Not really necessary at the CPU level, a good OS can allow you to do a RBAC rule that will block any file from being executed in a user writeable directory. It should be up to the OS to provide a complete security model. The thinking of putting overly complex security models into the CPU is wrong. This is because if a bug slips in its harder to update the CPU. The CPU has basic page functionality, NX bits, privelege levels adn so on that provide the basic tools needed for the OS to implement any security model needed.

Slashdot Top Deals

We don't know who it was that discovered water, but we're pretty sure that it wasn't a fish. -- Marshall McLuhan