Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Why? You can build the equivalent for less. (Score 1) 70

Two things that come to mind are: 1) Different games can allocate RAM differently to Graphics vs Main Memory based on expected workload. 2) Transfer of textures and other graphics components from Main to Graphics Memory is basically instantaneous as one just has to set a flag in the memory manager to mark the page as in GPU space.

Assuming they offer APIs to do this.

Comment Maybe we need two types of high school degrees (Score 1) 908

As universities offer two types of 4-year degrees, B.S. and B.A., it might make sense to have high schools do something similar. I know many schools have a separate college prep path, but maybe the split needs to be more nuanced as college becomes more common for all students. Or maybe at least common core standards need to reflect what most educational institutions already say some people are better at Mathematics and some are better at Language, Maybe graduates needs to do 2 years equivalent of both and 4 of one or the other. Though all students should have the option of doing 4 of both if they want.

Comment Re:I actually found this funny (Score 1) 908

A law class should be a mandatory part of the high school civics curriculum. I find it peculiar that politicians are always pushing more STEM into the curriculum, when many can participate in society just fine with little understanding of science behind what you do. But understanding the law is required for everyone in an "ignorance of the law is no excuse" system. You would think as lawyers they would understand that better than anyone. The conspiracy theorist in me would say it has something to do with their job security or manipulating the masses. Maybe the class could cover actually interacting with some bureaucracy for the experience. In the states that require it, maybe get a firearms ID so they can see exactly how easy it is to legally obtain a firearm. Or maybe come up with a half dozen permits and they can choose what to apply for. Maybe have them to learn some portion of the local penal code.

Right now the closest thing in most students take is probably Driver's Ed.

Comment Re:I actually found this funny (Score 2) 908

Formal logic should be taught to grammar school students as part of English class. Most of the base concepts involve simple words that children use everyday. There is no reason children can't introduced to a fuller understanding of conditional expressions, the use of 'and' and 'or', the difference between exclusive and inclusive or, common fallacies and arguments. Start at a section formally defining all these terms they use every day( "if", "when", "then", "until", "and", "or", "but", "only", "not") then end the section just brushing up against the concepts of philosophy.

Comment My biggest concern about systemd is not technical (Score 1) 928

Their image as an embrace and extend project. And more concernedly that they don't care that they are viewed this way. The big problem here that they could easily fix is breaking up their source repository into multiple smaller projects. I think the best example of this is "systemd-"consoled.  Now don't get me wrong I like consoled a lot. It looks like a great next gen production of kmscon. Which I also though was a really good innovation project. But there is no good reason it should be in the systemd git repo. systemd obiously doesn't need it and it doesn't need to be any more tightly integrated with systemd than X11 or mariadbd does.

They don't care that they are perceived as not understanding the importance of keeping things as loosely coupled as possible.

I guess the alternative is you look at the systemd repo as the whole Redhat system stack with the ability to pull out the subcomponents you want, but you are really taking part of a whole distro not one of many separate services. And it will be supported as such.

Comment My second biggest problem with systemd (Score 1) 928

Abandonment of classic config files and locations.The unit files are nice, but create a pretty large barrier to entry.  This has created the requirement for a lot of duplication of work and two different places in the file system to look for config info. The information in the .service files could have been added like the LSB headers to the /etc/init.d/* files.  The socket activation information could have been stored in inetd/xinetd compliant configurations with some ignorable syntax for adding named pipes and sockets. Automounts could have been parsed from /etc/auto.master. Fortunately they did this with /etc/fstab and the existing LSB headers at least.

I feel that most sys admin angst on systemd comes from the fact that they moved all the config files and created a new standard. They could have saved themselves a lot of ill will with this more backwards compatibility friendly configuration interface. instead of everything being a 20 character file name stuffed in one of the many systemd directories.

Comment Resource Activation (Score 1) 928

I like that systemd combines the functionality of insserv, inetd and autofs into a single resource activation model so that whether the resource is a file, a process, an IP socket, UNIX socket or a named pipe.  It manages everything. You don't have to worry about which resource kicked off or race conditions on processes tied to multiple resources. We could get to a point where things like mysqld could be reliably started by activation from either named socket or TCP/IP without concern for race condition. It really is inetd done right.

Comment Re:I Trust Debain (Score 1) 555

This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

Comment Re:I Trust Debain (Score 1) 555

This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

Comment Re:Ugh (Score 1) 727

I've always been a fan of WxWidgets. Which similar to QT is an application framework, but has really good native cross platform support. It tries to not re-implement too much basic C++ stuff (for example the deprecation of wxStrings with the improvements to STL strings).

The problem with designing something from the ground up everyone can agree on is getting everyone to agree. We will see where things like OpenGL-Next and Wayland go, but legacy support is always an issue and requiring everyone to quantum switch to a new interface is tough to coordinate. If the old interface is extensible the band-aid approach gets around a lot of these issues. A better move is to start to get serious about deprecating old parts of the API while adding new parts.  This way you can transition to a completely new interface and implementation without ever completely losing consistency.

Comment Terrible title hides lack of news. (Score 1) 155

Epigenitic changes are not changes in DNA, pretty much by definition.  They are the differences in gene expression caused by the chemistry of the surrounding environment. It is a fairly new field with the goal of finding the causes of differences between genetically identical subjects. The title should read, smoking expectant mothers adjust their body chemistry, possibly with long term impacts on their children's development.

Comment Misinformation rarely helps. (Score 1) 579

The problem with this is it kind of assumes maliciousness on the part of the drivers. That they must be kept in the dark in order to make the correct decision. If the problem is that they are using walk countdown timers to incorrectly determine when the light will change. Maybe adding a countdown timer to the traffic light would give them more accurate information. If they are being distracted by trying to gather information from a pedestrian light maybe putting the information directly in front of them would help them keep focus. If they are just trying to beat the light, they are foolishly looking for an accident.

Slashdot Top Deals

Economics is extremely useful as a form of employment for economists. -- John Kenneth Galbraith

Working...