I am not even remotely an expert on the matter, but I believe the point is to render at higher resolution and then reduce AA and such.

If you can make the game engine render the content at such a high resolution then there less need to do post processing of the images to do things like smooth edges as long as you have a way to efficiently scale down the image.

For instance the new Final Fantasy XIII PC port has no graphics options (update to fix that is supposed to be out tomorrow). You can't even pick resolution let alone AA and other settings, so you are stuck at 720p. So the community released a tool (GeToSaTo) that forces the game to 4k resolution and then downsamples it, so that even without AA enabled everything looks as it would if it were.

So the question is, is it harder for a GPU to render the scene at 4k with less post processing or at 2k with lots of post processing turned on to equal image quality? Apparently AMD and nVidia both have it now so at least some games must either look better or are more efficient using downsampling.

But they probably have thousands(millions?) of customers that eat at both chains. So if you happen to go to McDonalds for some reason they can correlate people who liked what you like at your chain to what those people liked at McDonalds to find what you would like with a reasonably high probability. The better your first experience at McDonalds the more likely you would be to return so having that data is very important.

Well boot times are not the only reason for systemd, so if they don't matter to you just consider them an added benefit then.

Care to elaborate? Are you actually running into problems? I haven't encountered any yet so I would genuinely like to know what kind of issues to expect other than the fud that seems to get passed around about systemd.

Haven you even tried systemd? are you aware of the defaults in this matter? http://www.freedesktop.org/sof... The restart option is disabled by default unless your service description calls for it. If you have a problem with the option of having a service restart maybe you should rip init out of your system because it has a respawn option as well?

Nothing. So as you can see at least in Red Hat apache will not restart itself. Other distros may change that, but either way it is an option and not mandatory in any way, so how is this a systemd problem to you? I for one like having the option to turn on auto restart even if I don't have a use for it, because maybe someday I will.

What distro are you using? My RHEL7/CentOS7 boxes mount NFS shares and start SysV scripts fine.

Did you actually add/enable the SysV scripts? chkconfig --add script_name && chkconfig script_name on && systemctl start script_name

True the syslog format is simple to use, easy to parse, etc, but it doesn't work all that well for anything more than simple logs. Journald allows us to start writing apps with better logging, i.e. json output which means things like multiline messages aren't such a mess, and we can spend less time parsing and more time searching.

And if you want to use your old tools there is nothing stopping you from doing what you used to, with the rsyslog text output from journald. Or else you can use journald to do the initial searching (more efficently since it is indexed), and then pipe the rest to the tools to narrow your results even more.

Syslog might be easy, but it is only adequate. Currently a good percentage of applications write their own log files because syslog is just unacceptable for what is needed to be logged (think java stack traces). In an ideal world we would have journalctl (or any other syslog replacement) that is capable of ingesting these more complicated formats so that everything on the system gets to logged to one place. Once we have these more complicated logs the simple tools for parsing are less adequate and binary formats help get around that.

We could just start logging json to syslog, but then your text readability goes downhill pretty fast unless you are piping the final output to a json parser that can pretty print it.

I have heard people mention possible problems with corruption with the journald binary formats. Has anyone seen an entire log file lost yet? I would think they would just be appending to the file anyways, so a corruption would just affect certain lines of the log, which would have been similarly affected with a text log.

Yes but add those 5 seconds up hundreds of times and they do add up to something. The real question is what are you loosing by cutting 5 seconds off of your boot times? I would assume nothing. And what are you gaining by cutting 5 seconds off of your boot time? You are gaining your time back,

Seems like the pros outweigh the cons to me.

I am well aware of when the POST has completed and when the operating system has started to load, and I am well aware that the majority of my time is wasted on the POST. Where exactly did you get this from? Did I say I was going to be saving minutes of time? I am just saying every second counts, and I don't see why people are so opposed to optimizing the software boot process. The hardware portion is out of our control/required to check all of the hardware but what is wrong with improving the rest of the process? Why keep something the way it is just because, if we have an option to make it faster?

Things change, accept it. We have a faster way to run things with no drawbacks* so let's do it!

* I know people mention various race conditions, missing dependencies and such, but if those problems aren't known and solved then they are bugs and should be fixed.

Sure I can see that. Looks like systemd has that covered for you http://www.freedesktop.org/sof... Check the restart option

Looks like restarting the service automatically is not the default. As far as notifications I assume that has nothing to do with your init because with all the bickering about ntp being in systemd I assume no one wants a SMTP service in systemd as well. Journald should of course log any stderr/stdout from the process that failed.

Well I guess I have no comment on the reason for the failure. Presumably if your fstab issue wasn't a critical one you should be able to at least login on the console and a simple systemctl command will show which services have failed (fstab entries show up in that list) and you will see which fstab entry failed, and which services didn't start up as a result.

I hear this all the time but I don't see where people keep getting it from. I manage several hundred servers and I would love faster boot times. Nothing worse than wasting my time waiting for a machine to come back online. I can be doing multiple things at once but it is a break in my concentration and it makes us less efficent. It would also be especially helpful when you are doing failover testing with servers that fence themselves. It is bad enough waiting for the BIOS to POST, so if we have an option to optimize the boot process then let's do it!

Also indexed logging is something that isn't really needed by people with a GUI, it's needed by system admins who actually need to look over their logs. My RHEL7 systems ship their logs just fine with syslog, but when I am on the system I love being able to filter logs with journald. I keep seeing people complain about not being able to grep/awk/whatever through their logs but pipe seems to work fine for me with journald.

As far as the learning curve goes your SysV scripts still work, and at least in Red Hat chkconfig still configures those SysV services so nothing to learn there. Logging is also setup to log to text files by default so with the exception of learning things like the systemd targets I don't see where there is really much of a learning curve. Most of the systemctl commands are pretty self explanatory and aren't really that much of a change.

How exactly is systemd any different in this respect? It is an application that runs, and it might have problems. We the system administrators may find ways around those problems and they are often shared on the internet for you to search for, and if they are really problems shouldn't they be fixed instead of us working aroudn them anyways? It sounds to me like you have been living with a system that presented you with problems and you are happy about that... Maybe with systemd we can break away from the "old way" so that instead of living with those problems, we can instead fix them! We can quit worrying about maintaining compatibility with every UNIX back to the 80s.

That is because all that you need for GIT is a local directory, SSH, or a Web server. Since your client has a full copy of the repository you can always just fire up gitweb on a local repository.

If you need a GUI to satisfy your needs there is the official web GUI that is distributed with git again no hosting required.
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgit.wiki.kernel.org%2Fin...

If you want more advanced features like Git Hub:
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fabout.gitlab.com%2F (a near clone of Git Hub)
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgitorious.org%2F
and dozens of others (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgit.wiki.kernel.org%2Findex.php%2FInterfaces%2C_frontends%2C_and_tools)

I will +1 on the sub-directories deal, but for my use case I just made the sub-directories GIT submodules and everything works itself out. If your sub-directories are really separate parts of a larger project you probably should already have them in separate repositories anyways.

I believe it varies by state, but here in Minnesota your employer is required to provide at least a 30 minute unpaid lunch break and 15 minute paid breaks for every 4 hours worked, but I can't imagine the state would make a law that says that you must take that break.

Requiring that the employee takes a lunch break is simply avoiding possible legal repercussions if an employee were to claim that the business worked them so hard that they were unable to take a break (which would mean that the business was breaking the above law). Putting it on the companies rule books that the employee must take a break is then just to avoid those claims. Also they probably don't want the employees eating at their desks on the clock, which probably isn't nearly as productive as clocking out and working the same amount of time later.

Just the biggest in the southern hemisphere. The biggest super computers in the northern half of the world still take up about football field sizes. (http://www.hpcwire.com/2013/06/02/full_details_uncovered_on_chinese_top_supercomputer/)

This is only required for digital output. If your TV doesn't have HDCP it probably doesn't have digital input anyways (although there was a while in there where they came with DVI plugs, and those TVs typically aren't HDCP compatible).

Presumably your TV has component input for analog HD signal, just find a blu-ray player that has component output for video (nothing specialized for this, many $100 players come with it), and optical/coaxial output for audio and then you are good to go with HD video, and surround sound. You only need a player. Like the previous poster mentioned you will max out at 1080i, but again if your TV doesn't have HDCP it probably isn't capable of more than that anyways.

The biggest difference (for me) is card support. I could fire up Kubuntu 13.10 with X server 1.14 on my old AGP ATI X1650 card and would work like it should. If proprietary drivers were the only choice I would be SOL. If I found the old driver that was designed for that card the chances of getting it to work with a modern kernel/X server would be extremely slim. The current Catalyst driver only supports back to the HD 5000 series so my desktops that I use on a daily basis with HD3*** and HD4*** cards are stuck with a Catalyst driver that says "Automated installer and Display Drivers for Xorg 6.9 to Xserver 1.12 and Kernel version up to 3.4", but they run great with the open source drivers.

I don't claim that the open source driver will support ancient cards forever, but AMD is concerned with selling new cards not keeping up old ones, and the open source drivers are much better in that department. If you know how you can always resort to fixing the issue yourself if the driver is broken for your card.

You probably wouldn't get downmodded if you were to explain WHY you would leave as soon as it is mandatory instead of just saying it.

You contributed nothing important to the conversation (slashdot cares about you as a means of making money, but the mods don't care about you leaving), and as such your post has been downmodded to make room for the more relevant posts.