The settled, high school science part is that CO2 causes warming (3.7W/m^2 per doubling). It's either that or almost all physics is wrong. The nearly-as-certain part is that water vapor provides a strong positive feedback loop. It holds true in both simple and complex models, and attempts to disprove that have failed. Frankly the alternate hypotheses never made sense; it's just wishful thinking to think that the climate is self-regulating. Beyond that things get complicated. The Earth will get warmer, and there are some possible scenarios that we'd really rather avoid, but the specifics are not high school science.
I hate to be the one to point it out, but if you're ignorant of which part of climate science is at the secondary education level, it seems your education is deficient. Any undergraduate text on Atmospheric Science would answer these questions. Also do note that Dyson is only arguing against the models' predictive power, not the underlying principles.
Keep in mind that 2 degrees C is a global average; the warming effect is greater at the poles. Alaska (and the Arctic, generally) is warming at twice the rate of the rest of the world. Fairbanks has seen a 50% increase in frost-free days since 1900, and glacial ice is melting at a mind-blowing rate.
The catastrophic type stuff is (hopefully) unlikely, but any of the large ice sheets melting would be seriously unpleasant and hard to stop. Similarly, most of the Arctic is underlain by permafrost, which will likely add gigatonnes of CO2/CH4 to the atmosphere if and when it melts. If one is willing to discount any ongoing warming in the Arctic, then 2 degrees C is probably survivable for most of humanity, assuming nothing else goes wrong. The concern is about reaching a "tipping point" where more powerful natural forces take over. And it's not like global oil consumption is declining.
No, I disagree. Science is empirical, and Computer "science" is rational. Computer science produces truth by means of mathematical proofs, not by observation and measurement. Mathematics by the same token is not empirical and not a science.
Text is searchable, skimmable, and can be read in far less time than it takes to say it. Which is one reason that there's always a dozen Slashdotters screaming for the editor's head on a plate if a video is posted without a transcript. It's also more accessible to people who may not have high speed Internet access everywhere they go.
Programming is a text-based job; video offers no advantages. It's not like code examples can be conveyed better with sight gags or interpretive dance. If you think video talks are superior to written documentation you are simply wrong.
So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.
You're aware that OpenRC does the exact same thing as systemd here, yes? That common library is written in C like God and Dennis Ritchie intended. Similarly, they annotate their files with dependency information and other useful info; many of the anti-systemd complaints apply equally to both projects.
No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
PID files are a bad hack. They are the reason cgroups exist, and why every other unix has replaced SysV init. And cgroups aren't even the first process tracking feature to land in Linux, just the one that actually got adopted.
The timeout is to allow startup to proceed in case of an error
So let's examine this a little. Init is the tool you use to change your system state by starting or stopping services, but it doesn't have any information about those services. It doesn't know if they're started, stopped, hung, or snake-bit. Each script has to provide that information, and while it does anything it gets the system's whole undivided attention. Sleeping in one script sleeps the entire startup. I know you know how stupid this is.
So when process tracking (cgroups) became a thing on Linux, it made sense to write a service management system built around it. If Linux had included such things at the beginning (and Eris only knows why it didn't) then we wouldn't have retarded things like PID files and we wouldn't be having this argument. But instead we have a quarter-century of technical debt. Dependency resolution is an obvious feature for a service manager, and so is parallelism -- OpenRC seems to agree. Most of the other design decisions of systemd are similarly obvious: a service manager should be able to start services on demand, or on a timer. There's no reason to look outside the ecosystem for a tool to do this, since the service manager has more information about the service and can respond intelligently if something goes wrong.
Ditching the veil of nostalgia, imagine if the roles were reversed: Linux had cgroups and something like systemd from the beginning, and J. Random Hacker proposes SysV init as a replacement: "Guys, the ability to have user-defined scripts in startup is awesome, but I want more. I want all the startup to be run as a script. The user will be in complete control, and if we don't use any Linux-specific features, we can be compatible with anything that speaks POSIX!" Or if the proposal was for OpenRC, you'd be talking about trading process tracking for broader compatibility, and you'd find the question of why Linux needs a POSIX-compatible service manager hard to answer.
Scientific truth is not the same thing as religious truth. There can be true statements in each system which contradict each other. Whether or not it is meaningful to compare truths arrived at by different methods is debatable.
Science is rooted in empiricism; truth is determined by observation. It's well suited to producing truths about things which can be isolated in an experiment. Things like economies, law/morality, and mathematics are more or less intractable for science, and it cannot make many statements about supernatural beliefs. There is a branch of philosophy which regards the unproven or unprovable as false, but it's a minority viewpoint.
Religion is (perhaps surprisingly) fairly rational, as in rationalism. However, fundamentally its truth is rooted in received wisdom and not subject to test by observation (and to some degree not to reason either). Where religion makes statements about the observable world, it can and often does conflict with empirical truth. Sometimes these things are called miracles.
It is not true that the realms of science, religion, and logic do not overlap. Religion does not always confine itself to the intangible. Scientific theories are always dancing on the limits of observation. Personally, I don't think it's useful to try to reconcile different ways of determining truth, and I think you and John Paul II are with me on this one. I'm not aware of any sensible way to establish a value relation among them; each is necessary in its own domain.
That said, while in my moments of intellectual honesty I am agnostic, believing strongly in something contradicted by empirical truth is not usually something I can take very seriously.
My phone has a guest account. Also the payment applications have distinct passwords. That said, the only time in the last decade someone asked to use my phone, and I let them, it was apparently to try to score some xanax. Lesson learned: you may not borrow my phone. Homeless people have cell phones these days, if you don't have one (for some bizarre reason) ask one of them. I'll consider exceptions to this rule if I know where you sleep.
Yes. While it's hard to condone as good practice for a variety of reasons, as you say many businesses have the majority of their business logic running in Excel. Apparently bad code makes the world go around.
And there's a shit ton of CRUD apps that people want written that don't need anything of the sort. There's a world between high-performance computing and the most superficial use of a computer. Excel macros spring to mind, as an example. We can also draw a line between simple computation and more complex mathematics -- simple calculations are absolutely the computer's job.
To answer your "So what?": useful shit can be done even without having learned everything that you did. What useful purpose does elitism serve?
Upstart was much more limited in goals and utility than systemd, and it took (arguably) the wrong approach to dependency resolution. It was an evolutionary upgrade with many of the same problems as SysV init. Rightly or wrongly, systemd is using the functionality provided by cgroups to implement a more-or-less complete plumbing layer for Linux services. You could interpret that as codifying, standardizing, and integrating existing components and features, or you could interpret it as absorbing functionality that should be seperate. The reality is likely somewhere in between. A lot of this is sensible -- timers for example are an obvious part of service management. But there's a lot of pushback from people who are used to writing both the script and the cronjob ("...uphill both ways! and we liked it!") and want to be able to use any POSIX-compliant cron daemon they choose. That they choose to use the default one and can continue to do so with systemd is seemingly beside the point.
The detractors who accuse Poettering of creating his own OS are not completely wrong. We are moving from a period of recommendations (e.g. Linux Standard Base) to a more integrated system, which is expected to manage services intelligently instead of letting anything that wants to snag an interpreter do whatever it wants to the system. For most people it is a sudden and far-reaching change. It was not created suddenly, however, and the foundational technology shift (cgroups) could be mistaken for a small and subtle one. As I've said, I think that most of what has been built on the core systemd/crgoup functionality are fairly logical extensions. Handling e.g. user sessions should probably be a core part of init and system management, especially if you're going to use cgroups to manage those processes, and especially if no one else is doing it. I'm sorry you're having hibernation issues, but I don't think you've even stopped to consider the idea behind systemd before passing judgment on it. If Linux had cgroups when it was first written, every part of systemd would have been written by someone else already; it makes too much sense to not use the functionality. Upstart would use them, and it would still probably have been replaced by something that starts dependencies on demand. Certain decisions about systemd components may not have been made with your use-case in mind, and I'm sure that like any other piece of software, bugs abound, but it is certainly not a "dumb idea": it's the way forward. The days where the only job of the OS was to start an interpreter are over.
You haven't been paying attention these last 20 years when every unix vendor has replaced SysV init with something else.
Writing init scripts is not a one time annoyance, at least not for distro maintainers. They are also not portable between distributions, as systemd unit files are. SysV init is also literally the dumbest form of init, where the init process has no information about dependencies, and cannot react sensibly to any changes in system state. Another sticking point involved the inability of the system to track processes accurately, which resulted in a number of kernel-level features over the years, of which cgroups are merely the most recent. Yes, it's fairly rare to have things go wrong, but pidfiles are unquestionably a bad hack.
Init is a misnomer. It was supposed to be the method by which your system changed states, but it was never very good at this, so people are used to thinking of it only as handling a few rare circumstances. The problem systemd solves is how to get the computer from state A to state B reliably, and guarantee that the services it manages are started properly. Startup and shutdown are special cases of this problem. It is built on kernel-level features that allow it to track processes accurately (and incidentally also track resource useage).
Systemd is the result of a number of (IMO) obvious choices. Cgroups exist, therefore it makes sense to write a service management tool to take advantage of them. As long as you're writing a service management tool, you should probably write in dependency resolution. Handling startup and shutdown is another logical choice. Also, since 95% of init script contents are common tasks, it makes sense to abstract out that stuff into a common C-based library. At this point it is relevant to note that, cgroups aside, OpenRC does this exact same thing.
Writing scripts is part of UNIX, and systemd coexists with them pretty happily. However, rewriting scripts into more flexible C libraries is also part of the UNIX tradition. What's so hot about these scripts, besides that you're more comfortable working with them?
You're not responding because you have no argument. Linux supports a wider range of hardware than any other kernel: ipso facto it has no driver model problem.
You have desktop myopia. Linux is not a desktop OS, neither are the BSDs, the commercial Unixes, or QNX. Yes, there have been efforts to force it into that space, but it's a minority of the development effort. As evidenced by popcon results, most Linux installs have no video output. Is that a desktop OS to you?
No dialog can be had with hairyfeet, whenever he's backed into a corner he cuts and runs, either changes to a different rant or just ignores the conversation entirely. No matter what happens you leave with your opinions intact.
I don't know what their problem is, but it clearly has nothing to do with the billions of Linux devices in existence.
lol, you think phones and servers are equivalent to the steam box?
I'm sure you were trying to express some sort of reasoned opinion. I'm less certain that you understood what you were responding to. Your comment is a complete non sequitur.
To be fair, I do need to thank the Linux developers for the "billions" of android phones that can be rooted. They keep on introducing new security vulnerabilities in every single release to let the users root their devices. Go Linux ! Yay !
Like every other phone OS I'm sure, but to be pedantic these are mostly AOSP vulnerabilities; you can thank Google for them. I'm sure you're having a wonderful time bashing Linux on random topics but we were talking about drivers, no?
Hairyfeet obviously knows when to quit. Anyone who can point to the kernel that supports a wider range of hardware than any other and say that it has driver problems is beyond help. Glad you stepped up to that plate. I'm not particularly interested in whatever random abuse you're interested in dealing out though, you obviously have no professional experience from which to speak.
When you need to use Linux, use it. When you need to use something else, use that. Tech is all about tradeoffs. If you don't understand what tradeoffs are being made, that's your cue to educate yourself. The easy answer is of course to assume that everyone who disagrees with you is ipso facto a moron: this is a puerile notion which rarely survives contact with the real world. In point of fact, the advantages of an open source operating system (especially one with broad hardware support) should be immediately obvious to any serious programmer. This is true even if it does not work perfectly, because no software works perfectly, and if you had software that met your every need you wouldn't be coding.
You, as a non-coder, have a different value proposition which leads you to prefer other software. You, as someone with an overly inflated opinion of their own intelligence, are trying to parlay what little experience you have into an ego boost at someone else's expense. Reading slashdot and using a desktop PC does indeed give you an advantage over Joe Average, but you are still woefully ill equipped for any serious discussion of computing.
Server OSes require constant system administration now? And desktop ones don't? I take it you've never administered either.
Valve is not a major OS vendor. I'd say that embarrassing is a good term for them though. I don't know what their problem is, but it clearly has nothing to do with the billions of Linux devices in existence.
You don't administer either desktops or servers. You don't use Linux. You don't program. You appear to have no idea what computers are used for besides Office and gaming. From this wealth of ignorance you have decided that Linux has driver issues. When pressed for evidence, you change the subject.You're doing a great APK impression.
So you just assert that it "DOES NOT WORK" because why? Desktop marketshare? Linux is not a desktop OS. The GUI is completely optional and it would not be less useful if it didn't have one at all. That is to say, its primary user interface is programmatic -- does that sound like something Joe Sixpack could use? The "by programmers, for programmers" operating system has actually been massively successful -- among programmers.
Updates, Android, whatever version of Windows you think is relevant, and whatever laptops you're talking about, are bizarre red herrings. You're saying that an OS which exists on a wider range of devices than any other has driver issues. I can understand why you'd want to drag in any other subject that would make you look less foolish, but that's what you get when your opinions are immune to reality. So your actual supporting evidence for this claim is what exactly?
There is no one best way to do software; it's always a matter of tradeoffs. You're a moron for thinking otherwise, and doubling down on stupid by asserting that every other OS follows the same rules. It's not even close to being true. What is it about the success of Linux that prevents you from even acknowledging it? Billions of devices run it: practically every smartphone and supercomputer, a good chunk of the embedded market, render farms and GPU computing clusters, raspberry pis — and you think that Linux should give up its "build-an-OS" heritage to cater to moronic desktop users? Because why, they'll sell more copies?
Learning to code would teach you a lot about how myopic your perspective on computing is. Failing that, I'd suggest taking a little input from the outside world from time to time, particularly from programmers about programming platforms. Failing that, you should reserve your rhetoric for subjects which you know something whereof.
Hey, you have the same bullshit criticism as last time, I have the same response, you presumably have the same lack of response. I'm going to be less polite here, because you're obviously trolling.
Linux does not need desktop marketshare, and having a closed driver model would be too great a price to pay. If that means trouble for Valve, too bad. However, the driver model actually has nothing to do with anything, and your predictions and your challenge are worthless. You do not have a clue what you are talking about. If the drivers are so terrible, how are there billions of Linux devices?
You're describing the legal reality. He's describing the actual practices. Copyright is something granted by law, and it is entirely correct to consider it as something which does not exist except at the determination of our legal system. Public domain is the natural state of all creative works. Jefferson gives a more eloquent statement:
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property.
Copyright infringement is in no way analogous to theft; I'm afraid you're the person with the profound misunderstanding.
I spent four years in Central America, in Costa Rica and Panama. I only wonder why this is news.
If you take a look at the Panama City skyline, it's pretty impressive. The population for the metropolitan area is only about 1.5 million though, so why all the skyscrapers? Who lives there?
No one. The government started investing in infrastructure after the Canal changed hands and they actually started getting money from it, and this fostered a booming construction trade. The construction companies thought that this government money was a grand idea, and the best way to keep it flowing is obviously to kick some of it back to the government officials. The government has spend the last decade trying to hide the debt that has been piling up as a result of this, and the only thing that I can say is that at least some of the money went into infrastructure.
Corruption is the expected norm in the entirety of Central America. It's how things are done there. I've bribed police there myself, and one of my friends was elected Representante de Panama while I was there: I can confirm that this operates the same way on all levels. The only reason I can think of why this would show up in the news at all is that someone didn't get paid enough. Where is the story here?
This snow clearing suggestion probably works, except for heavy snowfalls. Upstate New York, e.g., or the Chugach. I'm from Valdez and the concept is hilarious. Plus heating up snow is an energy-intensive operation, and any time you've had snow it must necessarily have been overcast, and in Alaska that means that you're probably dealing with less than six hours of daylight. I'd say the method of clearing the panels with the best ROI would be to say, "Fuck it" and drink until springtime, but that's how I approach most issues with winter in that State. It's a very popular strategy as I'm sure you've noticed.
Your trinity is entirely correct, so what is the business case for open source software? Clearly there is one: even Microsoft is getting in on the game.
Your examples of Linux software are a bit off base. In Debian's most popular packages, you have to go down to #259 to get to x11-common, and the first actual graphical program (iceweasel) comes in at #657. I understand that you're a desktop user and your business involves selling desktops, but I do wish that you would get past your myopic focus. Linux is a server OS, a development platform, an embedded and supercomputing platform, and while it can be used as a Desktop OS, there's really not much business interest in that.
I think you must be unaware that the majority of software is written to save money, not to make money. There's also a huge hidden cost to software: it doesn't exist in a vacuum. "Though a program be but three lines long, someday it will have to be maintained." The cost of maintaining software for which you don't have the source code tends to be "finitely large".
You're correct in what you say, up until you identify it as a flaw. Yes, it probably keeps Linux off the desktop. I'm sure that Mark Shuttleworth cries himself to sleep over that, but I'm sure Linus couldn't give a shit, and neither do the rest of the companies which have invested untold billions of dollars worth of developer time into the Linux ecosystem.
Failed driver model? By what definition of failure? Linux exists on millions upon millions of devices. Many Linux advocates may recommend NVIDIA hardware for gaming, but who cares? It's a tiny market. NVIDIA and AMD both have great Linux support for workstations and GPU computing, which is where the money is.
I hope that Linux never gets above 2% of the desktop, personally. Non-coders like you would ruin the platform, with exactly these kinds of moronic suggestions. I'd lay odds the majority of linux instances don't even have a video output connected. Why you persist in thinking of it as a desktop platform, to the exclusion of its actual uses, is beyond imagining.
Stick to what you know, hairyfeet. Linux has no ABI because it does not want to encourage having random binary blobs on the users' systems. It's an ideological principle that will never change.
You clearly only understand the desktop arena, which is fine, but most Linux users are pretty happy with its current niche. The Linux ecosystem is probably better described as a set of tools for building an OS, and so you see things made from it like Android, Maemo/Meego/Sailfish/Whatever, SteamOS, various container-style projects, and the normal run of distributions. It's a development platform, mostly for server applications. Yeah, it would be nice in some ways if everyone was programmer enough to use Linux, but it's essential to no one, and the minority of people who have aftermarket video cards is not sufficient justification to bend over backwards for closed development models. Gamers may keep you in business, but they are a tiny part of the computing market. Now if you could point to something like ABI compatibility being an issue with GPU supercomputing, that might be more compelling.
There are arguments for a stable ABI. They are never going to get traction in a very successful open development paradigm, and desktop market share is not one of them. I'm sorry you've been riding this hobby horse for however many years, and I hate to tell you how silly you look doing it, but if that's your thing I guess you can keep it up until doomsday.
Hanford was not a power plant, it was a bomb-making facility. The first bomb-making facility, in point of fact, which is why it's such a mess now. Thanks for being an alarmist on this issue, it really helps the level of discussion to drag in FUD about plutonium production when talking about power production.
Slashdot Mirror
The settled, high school science part is that CO2 causes warming (3.7W/m^2 per doubling). It's either that or almost all physics is wrong. The nearly-as-certain part is that water vapor provides a strong positive feedback loop. It holds true in both simple and complex models, and attempts to disprove that have failed. Frankly the alternate hypotheses never made sense; it's just wishful thinking to think that the climate is self-regulating. Beyond that things get complicated. The Earth will get warmer, and there are some possible scenarios that we'd really rather avoid, but the specifics are not high school science.
I hate to be the one to point it out, but if you're ignorant of which part of climate science is at the secondary education level, it seems your education is deficient. Any undergraduate text on Atmospheric Science would answer these questions. Also do note that Dyson is only arguing against the models' predictive power, not the underlying principles.
Keep in mind that 2 degrees C is a global average; the warming effect is greater at the poles. Alaska (and the Arctic, generally) is warming at twice the rate of the rest of the world. Fairbanks has seen a 50% increase in frost-free days since 1900, and glacial ice is melting at a mind-blowing rate.
The catastrophic type stuff is (hopefully) unlikely, but any of the large ice sheets melting would be seriously unpleasant and hard to stop. Similarly, most of the Arctic is underlain by permafrost, which will likely add gigatonnes of CO2/CH4 to the atmosphere if and when it melts. If one is willing to discount any ongoing warming in the Arctic, then 2 degrees C is probably survivable for most of humanity, assuming nothing else goes wrong. The concern is about reaching a "tipping point" where more powerful natural forces take over. And it's not like global oil consumption is declining.
No, I disagree. Science is empirical, and Computer "science" is rational. Computer science produces truth by means of mathematical proofs, not by observation and measurement. Mathematics by the same token is not empirical and not a science.
Text is searchable, skimmable, and can be read in far less time than it takes to say it. Which is one reason that there's always a dozen Slashdotters screaming for the editor's head on a plate if a video is posted without a transcript. It's also more accessible to people who may not have high speed Internet access everywhere they go.
Programming is a text-based job; video offers no advantages. It's not like code examples can be conveyed better with sight gags or interpretive dance. If you think video talks are superior to written documentation you are simply wrong.
So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.
You're aware that OpenRC does the exact same thing as systemd here, yes? That common library is written in C like God and Dennis Ritchie intended. Similarly, they annotate their files with dependency information and other useful info; many of the anti-systemd complaints apply equally to both projects.
No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
PID files are a bad hack. They are the reason cgroups exist, and why every other unix has replaced SysV init. And cgroups aren't even the first process tracking feature to land in Linux, just the one that actually got adopted.
The timeout is to allow startup to proceed in case of an error
So let's examine this a little. Init is the tool you use to change your system state by starting or stopping services, but it doesn't have any information about those services. It doesn't know if they're started, stopped, hung, or snake-bit. Each script has to provide that information, and while it does anything it gets the system's whole undivided attention. Sleeping in one script sleeps the entire startup. I know you know how stupid this is.
So when process tracking (cgroups) became a thing on Linux, it made sense to write a service management system built around it. If Linux had included such things at the beginning (and Eris only knows why it didn't) then we wouldn't have retarded things like PID files and we wouldn't be having this argument. But instead we have a quarter-century of technical debt. Dependency resolution is an obvious feature for a service manager, and so is parallelism -- OpenRC seems to agree. Most of the other design decisions of systemd are similarly obvious: a service manager should be able to start services on demand, or on a timer. There's no reason to look outside the ecosystem for a tool to do this, since the service manager has more information about the service and can respond intelligently if something goes wrong.
Ditching the veil of nostalgia, imagine if the roles were reversed: Linux had cgroups and something like systemd from the beginning, and J. Random Hacker proposes SysV init as a replacement: "Guys, the ability to have user-defined scripts in startup is awesome, but I want more. I want all the startup to be run as a script. The user will be in complete control, and if we don't use any Linux-specific features, we can be compatible with anything that speaks POSIX!" Or if the proposal was for OpenRC, you'd be talking about trading process tracking for broader compatibility, and you'd find the question of why Linux needs a POSIX-compatible service manager hard to answer.
Scientific truth is not the same thing as religious truth. There can be true statements in each system which contradict each other. Whether or not it is meaningful to compare truths arrived at by different methods is debatable.
Science is rooted in empiricism; truth is determined by observation. It's well suited to producing truths about things which can be isolated in an experiment. Things like economies, law/morality, and mathematics are more or less intractable for science, and it cannot make many statements about supernatural beliefs. There is a branch of philosophy which regards the unproven or unprovable as false, but it's a minority viewpoint.
Religion is (perhaps surprisingly) fairly rational, as in rationalism. However, fundamentally its truth is rooted in received wisdom and not subject to test by observation (and to some degree not to reason either). Where religion makes statements about the observable world, it can and often does conflict with empirical truth. Sometimes these things are called miracles.
It is not true that the realms of science, religion, and logic do not overlap. Religion does not always confine itself to the intangible. Scientific theories are always dancing on the limits of observation. Personally, I don't think it's useful to try to reconcile different ways of determining truth, and I think you and John Paul II are with me on this one. I'm not aware of any sensible way to establish a value relation among them; each is necessary in its own domain.
That said, while in my moments of intellectual honesty I am agnostic, believing strongly in something contradicted by empirical truth is not usually something I can take very seriously.
My phone has a guest account. Also the payment applications have distinct passwords. That said, the only time in the last decade someone asked to use my phone, and I let them, it was apparently to try to score some xanax. Lesson learned: you may not borrow my phone. Homeless people have cell phones these days, if you don't have one (for some bizarre reason) ask one of them. I'll consider exceptions to this rule if I know where you sleep.
Good or bad example?
Yes. While it's hard to condone as good practice for a variety of reasons, as you say many businesses have the majority of their business logic running in Excel. Apparently bad code makes the world go around.
And there's a shit ton of CRUD apps that people want written that don't need anything of the sort. There's a world between high-performance computing and the most superficial use of a computer. Excel macros spring to mind, as an example. We can also draw a line between simple computation and more complex mathematics -- simple calculations are absolutely the computer's job.
To answer your "So what?": useful shit can be done even without having learned everything that you did. What useful purpose does elitism serve?
Upstart was much more limited in goals and utility than systemd, and it took (arguably) the wrong approach to dependency resolution. It was an evolutionary upgrade with many of the same problems as SysV init. Rightly or wrongly, systemd is using the functionality provided by cgroups to implement a more-or-less complete plumbing layer for Linux services. You could interpret that as codifying, standardizing, and integrating existing components and features, or you could interpret it as absorbing functionality that should be seperate. The reality is likely somewhere in between. A lot of this is sensible -- timers for example are an obvious part of service management. But there's a lot of pushback from people who are used to writing both the script and the cronjob ("...uphill both ways! and we liked it!") and want to be able to use any POSIX-compliant cron daemon they choose. That they choose to use the default one and can continue to do so with systemd is seemingly beside the point.
The detractors who accuse Poettering of creating his own OS are not completely wrong. We are moving from a period of recommendations (e.g. Linux Standard Base) to a more integrated system, which is expected to manage services intelligently instead of letting anything that wants to snag an interpreter do whatever it wants to the system. For most people it is a sudden and far-reaching change. It was not created suddenly, however, and the foundational technology shift (cgroups) could be mistaken for a small and subtle one. As I've said, I think that most of what has been built on the core systemd/crgoup functionality are fairly logical extensions. Handling e.g. user sessions should probably be a core part of init and system management, especially if you're going to use cgroups to manage those processes, and especially if no one else is doing it. I'm sorry you're having hibernation issues, but I don't think you've even stopped to consider the idea behind systemd before passing judgment on it. If Linux had cgroups when it was first written, every part of systemd would have been written by someone else already; it makes too much sense to not use the functionality. Upstart would use them, and it would still probably have been replaced by something that starts dependencies on demand. Certain decisions about systemd components may not have been made with your use-case in mind, and I'm sure that like any other piece of software, bugs abound, but it is certainly not a "dumb idea": it's the way forward. The days where the only job of the OS was to start an interpreter are over.
You haven't been paying attention these last 20 years when every unix vendor has replaced SysV init with something else.
Writing init scripts is not a one time annoyance, at least not for distro maintainers. They are also not portable between distributions, as systemd unit files are. SysV init is also literally the dumbest form of init, where the init process has no information about dependencies, and cannot react sensibly to any changes in system state. Another sticking point involved the inability of the system to track processes accurately, which resulted in a number of kernel-level features over the years, of which cgroups are merely the most recent. Yes, it's fairly rare to have things go wrong, but pidfiles are unquestionably a bad hack.
Init is a misnomer. It was supposed to be the method by which your system changed states, but it was never very good at this, so people are used to thinking of it only as handling a few rare circumstances. The problem systemd solves is how to get the computer from state A to state B reliably, and guarantee that the services it manages are started properly. Startup and shutdown are special cases of this problem. It is built on kernel-level features that allow it to track processes accurately (and incidentally also track resource useage).
Systemd is the result of a number of (IMO) obvious choices. Cgroups exist, therefore it makes sense to write a service management tool to take advantage of them. As long as you're writing a service management tool, you should probably write in dependency resolution. Handling startup and shutdown is another logical choice. Also, since 95% of init script contents are common tasks, it makes sense to abstract out that stuff into a common C-based library. At this point it is relevant to note that, cgroups aside, OpenRC does this exact same thing.
Writing scripts is part of UNIX, and systemd coexists with them pretty happily. However, rewriting scripts into more flexible C libraries is also part of the UNIX tradition. What's so hot about these scripts, besides that you're more comfortable working with them?
You're not responding because you have no argument. Linux supports a wider range of hardware than any other kernel: ipso facto it has no driver model problem.
You have desktop myopia. Linux is not a desktop OS, neither are the BSDs, the commercial Unixes, or QNX. Yes, there have been efforts to force it into that space, but it's a minority of the development effort. As evidenced by popcon results, most Linux installs have no video output. Is that a desktop OS to you?
No dialog can be had with hairyfeet, whenever he's backed into a corner he cuts and runs, either changes to a different rant or just ignores the conversation entirely. No matter what happens you leave with your opinions intact.
Thank you, that was hilarious. I don't think I could ever explain quite how that was funny to anyone who didn't work in tech, but I laughed anyway.
I don't know what their problem is, but it clearly has nothing to do with the billions of Linux devices in existence.
lol, you think phones and servers are equivalent to the steam box?
I'm sure you were trying to express some sort of reasoned opinion. I'm less certain that you understood what you were responding to. Your comment is a complete non sequitur.
To be fair, I do need to thank the Linux developers for the "billions" of android phones that can be rooted. They keep on introducing new security vulnerabilities in every single release to let the users root their devices. Go Linux ! Yay !
Like every other phone OS I'm sure, but to be pedantic these are mostly AOSP vulnerabilities; you can thank Google for them. I'm sure you're having a wonderful time bashing Linux on random topics but we were talking about drivers, no?
Hairyfeet obviously knows when to quit. Anyone who can point to the kernel that supports a wider range of hardware than any other and say that it has driver problems is beyond help. Glad you stepped up to that plate. I'm not particularly interested in whatever random abuse you're interested in dealing out though, you obviously have no professional experience from which to speak.
When you need to use Linux, use it. When you need to use something else, use that. Tech is all about tradeoffs. If you don't understand what tradeoffs are being made, that's your cue to educate yourself. The easy answer is of course to assume that everyone who disagrees with you is ipso facto a moron: this is a puerile notion which rarely survives contact with the real world. In point of fact, the advantages of an open source operating system (especially one with broad hardware support) should be immediately obvious to any serious programmer. This is true even if it does not work perfectly, because no software works perfectly, and if you had software that met your every need you wouldn't be coding.
You, as a non-coder, have a different value proposition which leads you to prefer other software. You, as someone with an overly inflated opinion of their own intelligence, are trying to parlay what little experience you have into an ego boost at someone else's expense. Reading slashdot and using a desktop PC does indeed give you an advantage over Joe Average, but you are still woefully ill equipped for any serious discussion of computing.
Server OSes require constant system administration now? And desktop ones don't? I take it you've never administered either.
Valve is not a major OS vendor. I'd say that embarrassing is a good term for them though. I don't know what their problem is, but it clearly has nothing to do with the billions of Linux devices in existence.
You don't administer either desktops or servers. You don't use Linux. You don't program. You appear to have no idea what computers are used for besides Office and gaming. From this wealth of ignorance you have decided that Linux has driver issues. When pressed for evidence, you change the subject.You're doing a great APK impression.
So you just assert that it "DOES NOT WORK" because why? Desktop marketshare? Linux is not a desktop OS. The GUI is completely optional and it would not be less useful if it didn't have one at all. That is to say, its primary user interface is programmatic -- does that sound like something Joe Sixpack could use? The "by programmers, for programmers" operating system has actually been massively successful -- among programmers.
Updates, Android, whatever version of Windows you think is relevant, and whatever laptops you're talking about, are bizarre red herrings. You're saying that an OS which exists on a wider range of devices than any other has driver issues. I can understand why you'd want to drag in any other subject that would make you look less foolish, but that's what you get when your opinions are immune to reality. So your actual supporting evidence for this claim is what exactly?
2% DESKTOP. And may it stay that way.
There is no one best way to do software; it's always a matter of tradeoffs. You're a moron for thinking otherwise, and doubling down on stupid by asserting that every other OS follows the same rules. It's not even close to being true. What is it about the success of Linux that prevents you from even acknowledging it? Billions of devices run it: practically every smartphone and supercomputer, a good chunk of the embedded market, render farms and GPU computing clusters, raspberry pis — and you think that Linux should give up its "build-an-OS" heritage to cater to moronic desktop users? Because why, they'll sell more copies?
Learning to code would teach you a lot about how myopic your perspective on computing is. Failing that, I'd suggest taking a little input from the outside world from time to time, particularly from programmers about programming platforms. Failing that, you should reserve your rhetoric for subjects which you know something whereof.
Hey, you have the same bullshit criticism as last time, I have the same response, you presumably have the same lack of response. I'm going to be less polite here, because you're obviously trolling.
Linux does not need desktop marketshare, and having a closed driver model would be too great a price to pay. If that means trouble for Valve, too bad. However, the driver model actually has nothing to do with anything, and your predictions and your challenge are worthless. You do not have a clue what you are talking about. If the drivers are so terrible, how are there billions of Linux devices?
You're describing the legal reality. He's describing the actual practices. Copyright is something granted by law, and it is entirely correct to consider it as something which does not exist except at the determination of our legal system. Public domain is the natural state of all creative works. Jefferson gives a more eloquent statement:
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property.
Copyright infringement is in no way analogous to theft; I'm afraid you're the person with the profound misunderstanding.
I spent four years in Central America, in Costa Rica and Panama. I only wonder why this is news.
If you take a look at the Panama City skyline, it's pretty impressive. The population for the metropolitan area is only about 1.5 million though, so why all the skyscrapers? Who lives there?
No one. The government started investing in infrastructure after the Canal changed hands and they actually started getting money from it, and this fostered a booming construction trade. The construction companies thought that this government money was a grand idea, and the best way to keep it flowing is obviously to kick some of it back to the government officials. The government has spend the last decade trying to hide the debt that has been piling up as a result of this, and the only thing that I can say is that at least some of the money went into infrastructure.
Corruption is the expected norm in the entirety of Central America. It's how things are done there. I've bribed police there myself, and one of my friends was elected Representante de Panama while I was there: I can confirm that this operates the same way on all levels. The only reason I can think of why this would show up in the news at all is that someone didn't get paid enough. Where is the story here?
This snow clearing suggestion probably works, except for heavy snowfalls. Upstate New York, e.g., or the Chugach. I'm from Valdez and the concept is hilarious. Plus heating up snow is an energy-intensive operation, and any time you've had snow it must necessarily have been overcast, and in Alaska that means that you're probably dealing with less than six hours of daylight. I'd say the method of clearing the panels with the best ROI would be to say, "Fuck it" and drink until springtime, but that's how I approach most issues with winter in that State. It's a very popular strategy as I'm sure you've noticed.
Your trinity is entirely correct, so what is the business case for open source software? Clearly there is one: even Microsoft is getting in on the game.
Your examples of Linux software are a bit off base. In Debian's most popular packages, you have to go down to #259 to get to x11-common, and the first actual graphical program (iceweasel) comes in at #657. I understand that you're a desktop user and your business involves selling desktops, but I do wish that you would get past your myopic focus. Linux is a server OS, a development platform, an embedded and supercomputing platform, and while it can be used as a Desktop OS, there's really not much business interest in that.
I think you must be unaware that the majority of software is written to save money, not to make money. There's also a huge hidden cost to software: it doesn't exist in a vacuum. "Though a program be but three lines long, someday it will have to be maintained." The cost of maintaining software for which you don't have the source code tends to be "finitely large".
You're correct in what you say, up until you identify it as a flaw. Yes, it probably keeps Linux off the desktop. I'm sure that Mark Shuttleworth cries himself to sleep over that, but I'm sure Linus couldn't give a shit, and neither do the rest of the companies which have invested untold billions of dollars worth of developer time into the Linux ecosystem.
Failed driver model? By what definition of failure? Linux exists on millions upon millions of devices. Many Linux advocates may recommend NVIDIA hardware for gaming, but who cares? It's a tiny market. NVIDIA and AMD both have great Linux support for workstations and GPU computing, which is where the money is.
I hope that Linux never gets above 2% of the desktop, personally. Non-coders like you would ruin the platform, with exactly these kinds of moronic suggestions. I'd lay odds the majority of linux instances don't even have a video output connected. Why you persist in thinking of it as a desktop platform, to the exclusion of its actual uses, is beyond imagining.
Stick to what you know, hairyfeet. Linux has no ABI because it does not want to encourage having random binary blobs on the users' systems. It's an ideological principle that will never change.
You clearly only understand the desktop arena, which is fine, but most Linux users are pretty happy with its current niche. The Linux ecosystem is probably better described as a set of tools for building an OS, and so you see things made from it like Android, Maemo/Meego/Sailfish/Whatever, SteamOS, various container-style projects, and the normal run of distributions. It's a development platform, mostly for server applications. Yeah, it would be nice in some ways if everyone was programmer enough to use Linux, but it's essential to no one, and the minority of people who have aftermarket video cards is not sufficient justification to bend over backwards for closed development models. Gamers may keep you in business, but they are a tiny part of the computing market. Now if you could point to something like ABI compatibility being an issue with GPU supercomputing, that might be more compelling.
There are arguments for a stable ABI. They are never going to get traction in a very successful open development paradigm, and desktop market share is not one of them. I'm sorry you've been riding this hobby horse for however many years, and I hate to tell you how silly you look doing it, but if that's your thing I guess you can keep it up until doomsday.
Hanford was not a power plant, it was a bomb-making facility. The first bomb-making facility, in point of fact, which is why it's such a mess now. Thanks for being an alarmist on this issue, it really helps the level of discussion to drag in FUD about plutonium production when talking about power production.