Comment Re:QA (Score 1) 105
No, just no. The quality of OSS is too bad.
In some cases yes. But imagine how much it would improve if it got only 1/10th of what the state pours into proprietary solutions. And then everyone else would benefit too!
No, just no. The quality of OSS is too bad.
In some cases yes. But imagine how much it would improve if it got only 1/10th of what the state pours into proprietary solutions. And then everyone else would benefit too!
Present nothing. Say nothing. Do not open your mouth. Stare into space. Daydream.
...
And get convicted for obstructing justice. You are screwed either way.
Netflix streaming is evil?
The streaming itself is not evil. The particular implementation that prevents fair use is evil.
Users make the final decision
...
In order for market/democracy forces to work, the decision has to be an informed decision. It seldom is.
Also known as:
Harrisberger's Fourth Law of the Lab:
Experience is directly proportional to the amount of equipment ruined.
The other issue with ooBase/LibreBase is that you cannot visually design insert / update / delete queries using their QBE interface. Instead you have to write out all of the SQL.
Oh, really?
I have about a 30% duty cycle, on a typical day.
....For the most part, I try to fill my spare time with "fun" projects that just happen to marginally benefit my employer. But when something goes wrong, having me there to fix it in seconds rather than letting the company falter uselessly for days at a time more than justifies my salary.
Eh, that sounds familiar. But I have one question: do you have a report to write every week/month about what you did during that time period? Can you write there "I spent 70% of time sitting around and being ready to jump in when needed"?
You don't need to add debug output with systemd, because you don't need to write a script to start a daemon.
You never know what someone needs. If I decide to alter iptables firewall while some VPN daemon is running, or run ftpd only when samba runs,
If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. That is exactly the problem that systemd is designed to fix. You don't know what order services are starting in because you shouldn't need to.
If systemd does badly something it is designed to fix
You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.
Correct me if I'm wrong, but if all filesystems are mounted early, then it does not matter where you have moved the service. How can it be easier than that?
If any other distro want's to switch to systemd I could not care less. But the danger is that the software that runs on top will become dependent on systemd. Things like KDE, bind, sshd, samba, pppd,
Happy Slackware user since ~1995
Is it the case that as long as you don't have to deal with it and it works, then it's ok? What happens if you want to modify the service dependencies? Write your own deamon? Add some debug output here and there? Customize startup of some service?
All that currently requires me only to understand the bash syntax. In fact it currently requires only some familiarity with shell variables, "if" and "echo" and works from HP-UX, to FreeBSD, Slackware or Gentoo.
or do you enjoy having a 15s delay before chrome can be used; every time you start chrome?
Are you running it on Raspberry PI?
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.