I'm sure others can pipe in here with more detailed explanations because I am not that familiar with the Windows kernel, but the basic gist of the problem is that calls to this function (NtGdiCloseProcess) cause it to acquire a global kernel lock which blocks thread execution...for ~200 microseconds, usually. The problem in this scenario is that around 5,768 calls to this function are being serialized onto the Ready Thread call stack which, combined, are delaying all other processes that utilize that lock.
In summary, the delays in responsiveness and interactivity are being caused by context switches, which is the usual culprit. It has nothing to do with the speed and number of CPUs because it is not a CPU resource problem. It is purely a kernel scheduling issue.
And the K6 wasn't released until 1997 with an initial clock speed of 166 MHz. It wasn't until 1998 that it could achieve clock speeds of 300 MHz. It was late 1998/early 1999 before the 400 MHz K6-2 was released, which was also around the time you could max out the FSB with 512 Mb PC100 SDRAM (the pre-DDR era). So yeah, I think that while the GPs point is valid, his dates are a bit off.
Fair enough, but I'm still not quite sure what they expect to happen.
If I search for "cat videos", I do indeed get links from Vimeo and Dailymotion as well as Youtube, as you would expect. If I search for "shampoo", I get a large assortment of different pages: a Wikipedia article, an info pane for a hair salon, a few product advertisements, a few vendor pages, a few news articles on shampoo and health, etc.... If I search for "pantene shampoo", I get a nice aggregation of different vendors selling Pantene at different prices with star ratings, and below it I get links to the Pantene site, as well as a bunch of vendor search results. If I search for "shampoo price comparison", I get the same aggregated price results at the top, but I also get links to PriceSpy, Tesco, and PharmacyChecker. If I search for "shampoo" and then click on the "Shopping" tab I get the Google Shopping interface.
So what is it exactly that people are expecting that is different?
If the answer is is not in the top 20 search results, well, at the end of the day Google implements a search algorithm that tries to guess what you are looking for. If it doesn't guess right, that may be an imperfection in the algorithm, but it does not mean they are being dishonest.
If the answer is it should aggregate results from other sites in those nice aggregation panes...maybe, but which sites? Are the sites ok with that? Nextag, for example, like other price comparison sites, derives it's revenue from clicks on search results. So if Google chose to bypass that, like they do with their own Google Shopping results, the other sites probably wouldn't be too happy. If I search for "shampoo amazon", the first link is to a search query for shampoo on amazon.com, but it doesn't perform the search for you and aggregate the results back into the Google search results. It might be a nice feature if it could do that for a bunch of big vendor sites, but I don't think it is feasible or user-friendly for it to do that with all vendors, so some sort of ranking would have to be put into place.
If the answer is Google Shopping should display PriceGrabber/PriceSpy/Nextag results, I disagree. Google Shopping is clearly Google Shopping and it doesn't pretend to be anything else.
Imagine if you searched for a nearby pharmacy, then had to look up their hours,
Imagine looking up "pharmacy" in a convenient compilation of local businesses to find their telephone number...we could call this a "telephone book". Then calling them to find out their hours.;)
Joking aside, it is a bit astounding that the EC doesn't seem to quite get the value of aggregated information. Certainly, it would be nice for other price-comparison sites to be better represented, but I imagine there are a few technical details being missed. For example, if I search for "pantene shampoo", I get the Shopping results, but I also get 8 links to the Pantene site, 1 to Target, 1 to Walmart, and on the next page: image search results, Amazon results, a link to Ebay, Kmart, Costco, Walgreens.... So where does the other price comparison result go? Is Google suppose to find this site, run a search, and aggregate its result on the first page? Above Amazon? That doesn't really make sense when you consider how Google search works in the first place.
If you remove the Google Shopping result, you go back to scrolling through long lists of SEO page hits and clicking on each one to find what you are looking for, instead of just having the first ~10-15 shopping site results aggregated into a convenient format that is easy to quickly scroll through. And, by the way, if you click on a Shopping link, it takes you right to the vendor's product page. It doesn't give Google an ad click or any other kind of additional revenue. If other price-comparison sites were aggregated in the same way, they would likely complain because Google would be robbing them of the page views they would need draw advertisers.
What if drinkers tend to be more social? Just that single difference would introduce them to a whole host of different exposures when compared to non-drinkers, and none of those exposures would have anything to do with drinking itself.
I think you are hitting on something here. What if it is not that drinkers are more social, but that the social behaviors they tend to engage in are more risky? Does drinking influence people to engage in the risky social behaviors, or is it just coincidence? What does the answer to that question say about the risks of drinking?
Lots of unknowns here, agreed, but can't answer the question if you don't ask it.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question.
I have not made a concerted effort to learn about undocumented features of init. I have used the features various distributions have provided for me to use. That's why distributions exist after all. If I were interested in building my own distribution, maybe we would be having a different discussion. As it is, I am more interested in just maintaining my systems and keeping things running smoothly. So I use the distribution tools that are provided to me. In the past it was initd and I used it without complaint. Now it is systemd, and I'm glad for the change.
What you are arguing is a change of paradigm and mindset.
No, I'm not. I am simply accepting of the fact that distro maintainers have chosen to replace initd with systemd. I have learned the new tools. I like them. I don't see the huge problem.
You are arguing that complex is better than simple
No. I'm arguing that simple is not simple. It just seems that way because you are used to it. When you've piled up a bunch of hacks and workarounds and have become used to implementing on your own or doing without missing functionality, you may think everything is great but it's not.
and I am arguing that simple can become complex.
If you want to write it. That's the whole point. I don't want to write it. I want the functionality to just be there.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer.
You may think you are offering counter-rationalism, but you're not. Your entire argument boils down to "initd is better because I prefer doing things that way." You yourself have offered no other compelling reason for it. There is nothing wrong with a dissenting opinion, but understand that you are arguing for a preference, and other people have different preferences.
and I didn't call anyone an idiot
Well, I didn't call anyone an idiot either. So I guess we're even.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
Ok, I have time for one: socket activation. Tell me how to do that with initd. Don't say I don't need it. I want it. And don't say inetd. That's not good enough.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets.
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification. Fact is, it doesn't matter the justification. You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore. Like I said earlier, it comes down to a matter of preference. If you don't need it for your use cases and/or you prefer initd, that's fine. Go ahead and keep using it. Those of us that like systemd and need it will continue using it.
So far the answer is software to make the core features of initd available to a wider audience because they aren't being used
No. What it comes down to is, I don't want to replicate systemd functionality by writing a bunch of shell scripts. I know it can be done. Apparently you enjoy doing that sort of thing. I don't. I want core functionality (ie: booting a system with a complex set of dependencies) to be readily available by writing/modifying a few configuration files, and that's it. Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl
You claim that, but you still don't seem to know the difference between systemd and journald.
Guys like you are professing that it is so good that anyone using initd must be fucking idiot
Actually, if you look up in the thread, you will see that I am, and have been, saying the exact opposite. If you want/like initd, by all means keep using it. I have no problem with that. But if you call me an idiot for liking/preferring systemd, that's what I take issue with.
You and all the other systemd experts are supposed to tell me why I *should* use it
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude. But I don't see how I'm twisting your words. You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all. And you assert that somehow the principal operation of journald is so inherently different from syslogd that you lose information, which is just wrong.
And there we have it. You yourself are now citing Red Had's dumb serialization of initd's functionality with a crappy set of runlevel shell scripts and your limited understanding of initd's functionality
Speaking of twisting words, that is not what I said. However you choose to do it, rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
Salaries will drop, such that the personal incentives for work stay just as modest as they are now.
Not necessarily. Salaries will only drop if people are willing to work for less, which is not a given. A possibility equal to your scenario is that, with UBI place, people who feel more secure when employment lapses will not be willing to work for less and will demand more. Also possible, as the article alluded to, is people who feel they are not offered high enough wages may be more able to seek education or training so that they can move into a new job market that pays more, which would put upward pressure on wages. Markets are complicated.
Don't forget that the biggest negative incentives with our current system are not wages, but other benefits. Medicaid eligibility is the biggest one. Also on the list are things like WIC eligibility and subsidized housing. If you are collecting one or more of these benefits and move to employment (either full or part-time), you will very likely lose them (you will make too much money to qualify), which is a much greater loss than any marginal wage benefit.
So the GPP is absolutely right. UBI could dramatically increase personal incentives by resetting the poverty thresholds.
Well what are they? I keep asking this question and I get no clear answer.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
I see plenty of vendors and distributions not using initd properly.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No I don't, I just don't want my init process to do it.
Your init process (systemd) doesn't do it. Journald does.
You seem to thing having an highly active init process that generates I/O is a good thing
An event manager/dispatcher is going to generate I/O. I don't consider that a good or a bad thing inherently. It depends on how much (or if) you need the event manager. Considering that it is generating polling events at the same level as the watchdog and kworker threads, I don't think this is a huge problem to worry about. If you are going to make the argument that it causes significant application latency, then show me a real benchmark. Otherwise, this is just hand-wringing.
I think that initd could use a complementary event management subsystem, which is what I thought systemd was. If you understood how initd worked, the answer would be immediately apparent because it is obvious.
The only "obvious" thing that comes to mind from your description is an event manager that switches runlevels for you. Such a thing would be so inferior to what systemd does that it would laughable.
So what? unit files are going to run shell scripts
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
You are falling into the same flawed thinking all systemd proponents fall into,
Look, it's pointless to argue about this because it really comes down to a matter of needs and opinions. Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd. Furthermore, if you happen to like initd, you probably hate systemd. But it is not about right or flawed thinking. It is just a matter of opinion. You don't like systemd, that's fine you are entitled to your opinion.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources
Systemd as PID1 doesn't sleep. If you are looking at that and comparing it to an idle bash process, you are not looking at the right thing. There is a lot of documentation on benchmarking of systemd if you really care about it, but if not feel free to keep building up strawmen just so you can knock them down.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes
The same way syslog does. Do you also complain about syslogd hogging CPU resources? Seriously, what are you smoking?
No, it depends on one thing. Does the first process manage system processes or everything? An event manager is a system process listening and acting on events. They are two different things.
What if the event manager responds to events by spawning processes? I guess it would then need to signal some kind of event to the process manager to do that.... <head splodes>
When you are only confined by your imagination, anything is possible. You won't actually know, though, until you try to implement it. There are plenty of cases in software development where the ideal of perfect modularity has been compromised to meet practical benchmarks. Go talk to Linus sometime about monolithic vs microkernels if you don't believe me.
My conclusions is systemd has several fatal design flaws, some presented here, that make it unsuitable for server systems.
Well, for your use cases that may be true, but it clearly isn't generally true. Some of the most enthusiastic systemd adopters are server admins and systems integrators.
systemd has its own lib directory. It is a much more memory intensive process than init. No. I mean it generates interrupts for service from the CPU and steals context from other processes. If it write I/O it forces other processes to minor page fault back to ram and off the CPU core. Though I still have more research in this area about systemd behavior.
You are comparing apples and oranges. Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init. And systemd is much better in this regard than init.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
Which is not very useful if some problem causes you to loose your last buffer full of critical information that you need to determine why you system went down.
That doesn't happen.
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
Maybe, maybe not. It depends on a lot of things. If your events need to spawn processes and your processes send events, there's a good argument to be made that they can't be easily separated. As an analogy, in the old days of compositing window managers, it was originally thought that a separate compositing manager could be made that would just communicate with the window manager. That turned out not to work because compositing needed to know more about window placement than originally thought and window placement need to know more about the compositing layer, so the necessary bi-directional communication was just creating too much latency overhead.
Or maybe you want state-defined infrastructure and continuous integration, not just a bunch of ad-hoc scripts holding everything together with glue and tape. You can have logic in a config file if you think you really need it (see nginx, for example) without running a full blown interpreter with arbitrary code execution capabilities and complete freedom to operate as the root user anywhere on your system.
It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
How are you going to do local builds if you don't have the whole repository? In Microsoft's example, there is a separate build server and testing is sent off to a dedicated team, so the developer doesn't do any of that themselves. Git was designed to allow developers to checkout a repository and develop (which includes building and testing) completely offline. This model doesn't work for a large monolithic repository like Microsoft's; that's a fair criticism. But it wasn't the intended use case of git to be able to do that.
For some inexplicable reason a lot of people seem to think that if you want to use initd you don't know anything about systemd
It would help if you didn't reinforce that perception with such a poor use case justification.
initd isn't a large monolithic process that generates a lot of software interrupts
Systemd is not a large monolithic process. By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout. The difference really is whether there is a defined message pattern to the IPC (dbus) or just a dump of whatever data in whatever random format that has to be parsed by the receiving process (FIFO). While the latter has certainly worked, I think it is hard to argue against the former as a generally good practice.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running. The fact that they have lasted so long is a testament to how flexible the shell scripting languages are, but viewing it as anything other than a workaround for lack of necessary functionality in init is crazy.
journalctl and binary logging poses a threat to uptime and timely root cause analysis
Another argument that makes no sense whatsoever. Nothing inherent about binary logging prevents root cause analysis. Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd
You are contradicting yourself, because you just said,
we don't want a process manager to manage an event system we don't need
So, which is it?
It's a fair point to argue that initd worked fine for you and you don't see a reason to change and don't want to learn a new system. But just say that and save yourself the time.
Problem is, when it doesn't work it is 99% usually one of the following problems,
A) They intentionally broke it, or were doing something to workaround missing initd functionality and it clashed with systemd. For example, see above post where user is using wicd without disabling an already existing network daemon, probably networkmanager. They blame this on systemd. Solution: use a clean systemd distro, and migrate old configs on a case-by-case basis as the need arises. Many old and crusty initd workaround are no longer needed, and if you blindly go in trying to use them anyway, you are going to create problems for yourself.
B) Software has bugs in it, bugs that were not noticed before with initd because initd did not depend on that functionality working correctly. For example, see above post where user couldn't boot in degraded mode because of a bug in mdadm. They blame this on systemd when all systemd is doing is depending on mdadm to report the drive UUID correctly. The fix in mdadm fixes the problem. Probably, in this case, initd is not affected because it doesn't (or can be made to not) use the UUID when mounting the pool, which is a generally bad practice overall. There is a fair quibble to be had here with distro maintainers who have not properly vetted all aspects of the system to uncover these bugs earlier in the process, but getting these bugs out into the open is the only way they get fixed.
Seems easier than trying to manage independent source repos for dependencies.
If that's the only reason, then that's pretty silly. A decent dependency-management system is the right solution.
Let's say package A depends on packages B and C. B makes an incompatible change that breaks A, so A has to know that only the previous version of B will work without a patch. Patch goes in to A, and now new version of A works fine with new version of B. Meanwhile, a new feature in A requires an update to C, so C is updated and A development continues. A build/runtime-dependency system should be able to sort all of this out easily. Package A needs to specify which versions of B and C it is known to work with, and every time B and C are checked out, it is only those versions that are used. When B or C are updated, the new changes have to be vetted by the A team before they are incorporated into the build. If multiple packages also use B and C as dependencies, the respective teams either a) coordinate their updates to B and C so as to not break each other, and/or b) open separate branches of B and C and merge them at some later date, verifying that all of their unit tests are successful in the process. As a bonus, it should be relatively easy to rewind history a bit and build a prior version of A against older versions of B and C as well if you want to do some sort of differential code analysis. Everything is in the respective change histories, and all of the diffs are saved, so software should be able to do all of this.
The article summary also leaves out the minor point that MS had to write an entire abstraction layer underneath Git because it's so incapable of handling a large repository.
Not completely true. They call it GVFS, but all it really does is prevent the entire repository from being downloaded when you clone it. Instead it downloads "only what you need". And there are a couple of patches to make git aware that this is happening, so that it stats only what is local and not the whole repository. One might argue that since the developer teams are not working on the entire codebase at once but rather on, let's call them "modules", within the larger repository, then the repository itself should be made more modular that match this development pattern. That would be more inline with the way Git was designed in the first place, and these extensions would not be as necessary. Still, to have the capability is nice.
Just because your favorite version control system can't do something doesn't mean it's a bad idea.
No, but pick the right tool for the job. If you are not developing modular, self-contained code in a decentralized fashion, don't use a source control system designed with those explicit goals in mind.
Notice how LibreOffice splits up their fairly large codebase into several smaller repositories, https://github.com/LibreOffice
Interesting read, actually. They call it GVFS, but it is really just a more asynchronous mode for local git repositories. Traditional git downloads the whole repository as a local copy. It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches. It sounds like the Windows repository is a) large and monolithic, so a given developer team does not work on the entire codebase, and b) they frequently sync their changes to the central repository (ie: it is not really decentralized), so the traditional git model has shortcomings for them. One can argue about the structure of the Windows repository, but GVFS sounds like a nice feature to have regardless. The only question I have is...
The third thing the company has done is build a Git proxy server
Why didn't they just clone the Azure repository to somewhere on the East Coast? Git is designed to handle this type of replication, so why did they write a "proxy server" (not entirely sure what they mean by that).
There is a difference between having a right and how you choose to exercise/express it. It may be my right to stand up in front of a crowd and hurl racist insults at people, but that doesn't mean that I should do it or that it is conducive to a peaceful society. I get that it is your right to bear arms. I'm not trying to take that away. I'm just asking that you exercise some discretion and be reasonable about it. Clear enough for you?
Constitutionally-guaranteed freedoms are what we make compromises to ensure, not what we compromise.
There is the language of law (ie: the Constitution), and there is the interpretation of that language as it pertains to everyday situations. Compromise requires recognizing that there is more than one such interpretation, and that multiple interpretations can be equally valid depending on the circumstances. If you insist that there is only one valid interpretation (yours), it will never be possible to compromise.
Thanks for illustrating my point so clearly. When a liberal makes an off-hand sarcastic remark about a conservative president, you feel it's a threat that should be investigated by the secret service. But when liberals feel threatened by aggressive gun-wielding conservatives, they are just a bunch of sissies who need to shut up because its your Second Amendment right to carry around an AK-47 on a university campus.
If you really care about reaching an end to partisan intransigence, you should think about it a little bit. Trying to understand the other sides POV and compromising when necessary are critical to a functioning democracy.
Universities could use more funding, yes, but that's not really the source of the problem. Universities do basic research. A new mechanism of action for an antibiotic, for example. However, having made that discovery in an academic lab, there is a LONG way to go for it to make it to market. The short, non-exhaustive list, includes target identification, structure-activity relationship modeling, formulation, cell-based assays, pharmacokinetics and dosing, synthesis scale-up and purification, efficacy testing, safety testing, regulatory review...and all of that has to be done BEFORE it can be sent to manufacturing where there is another whole host of issues (production yields and purity, lot control, supply chain management, etc).
None of this is the domain of university-funded academic labs. Some of it might fall under the umbrella of "translational" research (aka "de-risking"), or could be covered by a non-profit group. But most of it has to be done by a commercial company. There is no other efficient way to handle such a complex product life cycle.
I'm not an anti-gun nut, unless you care to characterize yourself as a pro-gun nut. I don't care if you want to keep a gun for self-defense in your house, or go hunting, or go to the shooting range. I just don't see why you have to walk down the street brandishing a rifle claiming that it is some sort of Second Amendment right.
Anyway, they weren't "just walking around". It was an organized protest, and they were brandishing loaded guns. A person purposefully demonstrating their ability to shoot someone at any time is intimating violence. It is a warning and therefore a threat to do violence.
We don't have proper management. Hence the article, no?
Indeed. Well, I would say we are doing ok, but we need to do better. But finding new antibiotics without improving the effectiveness of antibiotic delivery will not likely be a sustainable solution.
Slashdot Mirror
+1 Funny
http://www.tothepc.com/pic/fak...
Short answer: context switching.
I'm sure others can pipe in here with more detailed explanations because I am not that familiar with the Windows kernel, but the basic gist of the problem is that calls to this function (NtGdiCloseProcess) cause it to acquire a global kernel lock which blocks thread execution...for ~200 microseconds, usually. The problem in this scenario is that around 5,768 calls to this function are being serialized onto the Ready Thread call stack which, combined, are delaying all other processes that utilize that lock.
In summary, the delays in responsiveness and interactivity are being caused by context switches, which is the usual culprit. It has nothing to do with the speed and number of CPUs because it is not a CPU resource problem. It is purely a kernel scheduling issue.
And the K6 wasn't released until 1997 with an initial clock speed of 166 MHz. It wasn't until 1998 that it could achieve clock speeds of 300 MHz. It was late 1998/early 1999 before the 400 MHz K6-2 was released, which was also around the time you could max out the FSB with 512 Mb PC100 SDRAM (the pre-DDR era). So yeah, I think that while the GPs point is valid, his dates are a bit off.
Fair enough, but I'm still not quite sure what they expect to happen.
If I search for "cat videos", I do indeed get links from Vimeo and Dailymotion as well as Youtube, as you would expect.
If I search for "shampoo", I get a large assortment of different pages: a Wikipedia article, an info pane for a hair salon, a few product advertisements, a few vendor pages, a few news articles on shampoo and health, etc....
If I search for "pantene shampoo", I get a nice aggregation of different vendors selling Pantene at different prices with star ratings, and below it I get links to the Pantene site, as well as a bunch of vendor search results.
If I search for "shampoo price comparison", I get the same aggregated price results at the top, but I also get links to PriceSpy, Tesco, and PharmacyChecker.
If I search for "shampoo" and then click on the "Shopping" tab I get the Google Shopping interface.
So what is it exactly that people are expecting that is different?
If the answer is is not in the top 20 search results, well, at the end of the day Google implements a search algorithm that tries to guess what you are looking for. If it doesn't guess right, that may be an imperfection in the algorithm, but it does not mean they are being dishonest.
If the answer is it should aggregate results from other sites in those nice aggregation panes...maybe, but which sites? Are the sites ok with that? Nextag, for example, like other price comparison sites, derives it's revenue from clicks on search results. So if Google chose to bypass that, like they do with their own Google Shopping results, the other sites probably wouldn't be too happy. If I search for "shampoo amazon", the first link is to a search query for shampoo on amazon.com, but it doesn't perform the search for you and aggregate the results back into the Google search results. It might be a nice feature if it could do that for a bunch of big vendor sites, but I don't think it is feasible or user-friendly for it to do that with all vendors, so some sort of ranking would have to be put into place.
If the answer is Google Shopping should display PriceGrabber/PriceSpy/Nextag results, I disagree. Google Shopping is clearly Google Shopping and it doesn't pretend to be anything else.
Imagine if you searched for a nearby pharmacy, then had to look up their hours,
Imagine looking up "pharmacy" in a convenient compilation of local businesses to find their telephone number...we could call this a "telephone book". Then calling them to find out their hours. ;)
Joking aside, it is a bit astounding that the EC doesn't seem to quite get the value of aggregated information. Certainly, it would be nice for other price-comparison sites to be better represented, but I imagine there are a few technical details being missed. For example, if I search for "pantene shampoo", I get the Shopping results, but I also get 8 links to the Pantene site, 1 to Target, 1 to Walmart, and on the next page: image search results, Amazon results, a link to Ebay, Kmart, Costco, Walgreens.... So where does the other price comparison result go? Is Google suppose to find this site, run a search, and aggregate its result on the first page? Above Amazon? That doesn't really make sense when you consider how Google search works in the first place.
If you remove the Google Shopping result, you go back to scrolling through long lists of SEO page hits and clicking on each one to find what you are looking for, instead of just having the first ~10-15 shopping site results aggregated into a convenient format that is easy to quickly scroll through. And, by the way, if you click on a Shopping link, it takes you right to the vendor's product page. It doesn't give Google an ad click or any other kind of additional revenue. If other price-comparison sites were aggregated in the same way, they would likely complain because Google would be robbing them of the page views they would need draw advertisers.
What if drinkers tend to be more social? Just that single difference would introduce them to a whole host of different exposures when compared to non-drinkers, and none of those exposures would have anything to do with drinking itself.
I think you are hitting on something here. What if it is not that drinkers are more social, but that the social behaviors they tend to engage in are more risky? Does drinking influence people to engage in the risky social behaviors, or is it just coincidence? What does the answer to that question say about the risks of drinking?
Lots of unknowns here, agreed, but can't answer the question if you don't ask it.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question.
I have not made a concerted effort to learn about undocumented features of init. I have used the features various distributions have provided for me to use. That's why distributions exist after all. If I were interested in building my own distribution, maybe we would be having a different discussion. As it is, I am more interested in just maintaining my systems and keeping things running smoothly. So I use the distribution tools that are provided to me. In the past it was initd and I used it without complaint. Now it is systemd, and I'm glad for the change.
What you are arguing is a change of paradigm and mindset.
No, I'm not. I am simply accepting of the fact that distro maintainers have chosen to replace initd with systemd. I have learned the new tools. I like them. I don't see the huge problem.
You are arguing that complex is better than simple
No. I'm arguing that simple is not simple. It just seems that way because you are used to it. When you've piled up a bunch of hacks and workarounds and have become used to implementing on your own or doing without missing functionality, you may think everything is great but it's not.
and I am arguing that simple can become complex.
If you want to write it. That's the whole point. I don't want to write it. I want the functionality to just be there.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer.
You may think you are offering counter-rationalism, but you're not. Your entire argument boils down to "initd is better because I prefer doing things that way." You yourself have offered no other compelling reason for it. There is nothing wrong with a dissenting opinion, but understand that you are arguing for a preference, and other people have different preferences.
and I didn't call anyone an idiot
Well, I didn't call anyone an idiot either. So I guess we're even.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
Ok, I have time for one: socket activation. Tell me how to do that with initd. Don't say I don't need it. I want it. And don't say inetd. That's not good enough.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets.
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification. Fact is, it doesn't matter the justification. You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore. Like I said earlier, it comes down to a matter of preference. If you don't need it for your use cases and/or you prefer initd, that's fine. Go ahead and keep using it. Those of us that like systemd and need it will continue using it.
So far the answer is software to make the core features of initd available to a wider audience because they aren't being used
No. What it comes down to is, I don't want to replicate systemd functionality by writing a bunch of shell scripts. I know it can be done. Apparently you enjoy doing that sort of thing. I don't. I want core functionality (ie: booting a system with a complex set of dependencies) to be readily available by writing/modifying a few configuration files, and that's it. Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl
You claim that, but you still don't seem to know the difference between systemd and journald.
Guys like you are professing that it is so good that anyone using initd must be fucking idiot
Actually, if you look up in the thread, you will see that I am, and have been, saying the exact opposite. If you want/like initd, by all means keep using it. I have no problem with that. But if you call me an idiot for liking/preferring systemd, that's what I take issue with.
You and all the other systemd experts are supposed to tell me why I *should* use it
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude. But I don't see how I'm twisting your words. You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all. And you assert that somehow the principal operation of journald is so inherently different from syslogd that you lose information, which is just wrong.
And there we have it. You yourself are now citing Red Had's dumb serialization of initd's functionality with a crappy set of runlevel shell scripts and your limited understanding of initd's functionality
Speaking of twisting words, that is not what I said. However you choose to do it, rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
http://www.manpages.info/linux...
Being forced into following fools who can't make an
Salaries will drop, such that the personal incentives for work stay just as modest as they are now.
Not necessarily. Salaries will only drop if people are willing to work for less, which is not a given. A possibility equal to your scenario is that, with UBI place, people who feel more secure when employment lapses will not be willing to work for less and will demand more. Also possible, as the article alluded to, is people who feel they are not offered high enough wages may be more able to seek education or training so that they can move into a new job market that pays more, which would put upward pressure on wages. Markets are complicated.
Don't forget that the biggest negative incentives with our current system are not wages, but other benefits. Medicaid eligibility is the biggest one. Also on the list are things like WIC eligibility and subsidized housing. If you are collecting one or more of these benefits and move to employment (either full or part-time), you will very likely lose them (you will make too much money to qualify), which is a much greater loss than any marginal wage benefit.
So the GPP is absolutely right. UBI could dramatically increase personal incentives by resetting the poverty thresholds.
Well what are they? I keep asking this question and I get no clear answer.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
I see plenty of vendors and distributions not using initd properly.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No I don't, I just don't want my init process to do it.
Your init process (systemd) doesn't do it. Journald does.
You seem to thing having an highly active init process that generates I/O is a good thing
An event manager/dispatcher is going to generate I/O. I don't consider that a good or a bad thing inherently. It depends on how much (or if) you need the event manager. Considering that it is generating polling events at the same level as the watchdog and kworker threads, I don't think this is a huge problem to worry about. If you are going to make the argument that it causes significant application latency, then show me a real benchmark. Otherwise, this is just hand-wringing.
I think that initd could use a complementary event management subsystem, which is what I thought systemd was. If you understood how initd worked, the answer would be immediately apparent because it is obvious.
The only "obvious" thing that comes to mind from your description is an event manager that switches runlevels for you. Such a thing would be so inferior to what systemd does that it would laughable.
So what? unit files are going to run shell scripts
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
You are falling into the same flawed thinking all systemd proponents fall into,
Look, it's pointless to argue about this because it really comes down to a matter of needs and opinions. Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd. Furthermore, if you happen to like initd, you probably hate systemd. But it is not about right or flawed thinking. It is just a matter of opinion. You don't like systemd, that's fine you are entitled to your opinion.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources
Systemd as PID1 doesn't sleep. If you are looking at that and comparing it to an idle bash process, you are not looking at the right thing. There is a lot of documentation on benchmarking of systemd if you really care about it, but if not feel free to keep building up strawmen just so you can knock them down.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes
The same way syslog does. Do you also complain about syslogd hogging CPU resources? Seriously, what are you smoking?
No, it depends on one thing. Does the first process manage system processes or everything? An event manager is a system process listening and acting on events. They are two different things.
What if the event manager responds to events by spawning processes? I guess it would then need to signal some kind of event to the process manager to do that.... <head splodes>
When you are only confined by your imagination, anything is possible. You won't actually know, though, until you try to implement it. There are plenty of cases in software development where the ideal of perfect modularity has been compromised to meet practical benchmarks. Go talk to Linus sometime about monolithic vs microkernels if you don't believe me.
My conclusions is systemd has several fatal design flaws, some presented here, that make it unsuitable for server systems.
Well, for your use cases that may be true, but it clearly isn't generally true. Some of the most enthusiastic systemd adopters are server admins and systems integrators.
systemd has its own lib directory. It is a much more memory intensive process than init.
No. I mean it generates interrupts for service from the CPU and steals context from other processes. If it write I/O it forces other processes to minor page fault back to ram and off the CPU core. Though I still have more research in this area about systemd behavior.
You are comparing apples and oranges. Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init. And systemd is much better in this regard than init.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
Which is not very useful if some problem causes you to loose your last buffer full of critical information that you need to determine why you system went down.
That doesn't happen.
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
Maybe, maybe not. It depends on a lot of things. If your events need to spawn processes and your processes send events, there's a good argument to be made that they can't be easily separated. As an analogy, in the old days of compositing window managers, it was originally thought that a separate compositing manager could be made that would just communicate with the window manager. That turned out not to work because compositing needed to know more about window placement than originally thought and window placement need to know more about the compositing layer, so the necessary bi-directional communication was just creating too much latency overhead.
Or maybe you want state-defined infrastructure and continuous integration, not just a bunch of ad-hoc scripts holding everything together with glue and tape. You can have logic in a config file if you think you really need it (see nginx, for example) without running a full blown interpreter with arbitrary code execution capabilities and complete freedom to operate as the root user anywhere on your system.
It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
How are you going to do local builds if you don't have the whole repository? In Microsoft's example, there is a separate build server and testing is sent off to a dedicated team, so the developer doesn't do any of that themselves. Git was designed to allow developers to checkout a repository and develop (which includes building and testing) completely offline. This model doesn't work for a large monolithic repository like Microsoft's; that's a fair criticism. But it wasn't the intended use case of git to be able to do that.
For some inexplicable reason a lot of people seem to think that if you want to use initd you don't know anything about systemd
It would help if you didn't reinforce that perception with such a poor use case justification.
initd isn't a large monolithic process that generates a lot of software interrupts
Systemd is not a large monolithic process. By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout. The difference really is whether there is a defined message pattern to the IPC (dbus) or just a dump of whatever data in whatever random format that has to be parsed by the receiving process (FIFO). While the latter has certainly worked, I think it is hard to argue against the former as a generally good practice.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running. The fact that they have lasted so long is a testament to how flexible the shell scripting languages are, but viewing it as anything other than a workaround for lack of necessary functionality in init is crazy.
journalctl and binary logging poses a threat to uptime and timely root cause analysis
Another argument that makes no sense whatsoever. Nothing inherent about binary logging prevents root cause analysis. Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd
You are contradicting yourself, because you just said,
we don't want a process manager to manage an event system we don't need
So, which is it?
It's a fair point to argue that initd worked fine for you and you don't see a reason to change and don't want to learn a new system. But just say that and save yourself the time.
Problem is, when it doesn't work it is 99% usually one of the following problems,
A) They intentionally broke it, or were doing something to workaround missing initd functionality and it clashed with systemd. For example, see above post where user is using wicd without disabling an already existing network daemon, probably networkmanager. They blame this on systemd. Solution: use a clean systemd distro, and migrate old configs on a case-by-case basis as the need arises. Many old and crusty initd workaround are no longer needed, and if you blindly go in trying to use them anyway, you are going to create problems for yourself.
B) Software has bugs in it, bugs that were not noticed before with initd because initd did not depend on that functionality working correctly. For example, see above post where user couldn't boot in degraded mode because of a bug in mdadm. They blame this on systemd when all systemd is doing is depending on mdadm to report the drive UUID correctly. The fix in mdadm fixes the problem. Probably, in this case, initd is not affected because it doesn't (or can be made to not) use the UUID when mounting the pool, which is a generally bad practice overall. There is a fair quibble to be had here with distro maintainers who have not properly vetted all aspects of the system to uncover these bugs earlier in the process, but getting these bugs out into the open is the only way they get fixed.
Seems easier than trying to manage independent source repos for dependencies.
If that's the only reason, then that's pretty silly. A decent dependency-management system is the right solution.
Let's say package A depends on packages B and C. B makes an incompatible change that breaks A, so A has to know that only the previous version of B will work without a patch. Patch goes in to A, and now new version of A works fine with new version of B. Meanwhile, a new feature in A requires an update to C, so C is updated and A development continues. A build/runtime-dependency system should be able to sort all of this out easily. Package A needs to specify which versions of B and C it is known to work with, and every time B and C are checked out, it is only those versions that are used. When B or C are updated, the new changes have to be vetted by the A team before they are incorporated into the build. If multiple packages also use B and C as dependencies, the respective teams either a) coordinate their updates to B and C so as to not break each other, and/or b) open separate branches of B and C and merge them at some later date, verifying that all of their unit tests are successful in the process. As a bonus, it should be relatively easy to rewind history a bit and build a prior version of A against older versions of B and C as well if you want to do some sort of differential code analysis. Everything is in the respective change histories, and all of the diffs are saved, so software should be able to do all of this.
The article summary also leaves out the minor point that MS had to write an entire abstraction layer underneath Git because it's so incapable of handling a large repository.
Not completely true. They call it GVFS, but all it really does is prevent the entire repository from being downloaded when you clone it. Instead it downloads "only what you need". And there are a couple of patches to make git aware that this is happening, so that it stats only what is local and not the whole repository. One might argue that since the developer teams are not working on the entire codebase at once but rather on, let's call them "modules", within the larger repository, then the repository itself should be made more modular that match this development pattern. That would be more inline with the way Git was designed in the first place, and these extensions would not be as necessary. Still, to have the capability is nice.
Just because your favorite version control system can't do something doesn't mean it's a bad idea.
No, but pick the right tool for the job. If you are not developing modular, self-contained code in a decentralized fashion, don't use a source control system designed with those explicit goals in mind.
Notice how LibreOffice splits up their fairly large codebase into several smaller repositories,
https://github.com/LibreOffice
Seems to work pretty well for them.
Interesting read, actually. They call it GVFS, but it is really just a more asynchronous mode for local git repositories. Traditional git downloads the whole repository as a local copy. It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches. It sounds like the Windows repository is a) large and monolithic, so a given developer team does not work on the entire codebase, and b) they frequently sync their changes to the central repository (ie: it is not really decentralized), so the traditional git model has shortcomings for them. One can argue about the structure of the Windows repository, but GVFS sounds like a nice feature to have regardless. The only question I have is...
The third thing the company has done is build a Git proxy server
Why didn't they just clone the Azure repository to somewhere on the East Coast? Git is designed to handle this type of replication, so why did they write a "proxy server" (not entirely sure what they mean by that).
There is a difference between having a right and how you choose to exercise/express it. It may be my right to stand up in front of a crowd and hurl racist insults at people, but that doesn't mean that I should do it or that it is conducive to a peaceful society. I get that it is your right to bear arms. I'm not trying to take that away. I'm just asking that you exercise some discretion and be reasonable about it. Clear enough for you?
Constitutionally-guaranteed freedoms are what we make compromises to ensure, not what we compromise.
There is the language of law (ie: the Constitution), and there is the interpretation of that language as it pertains to everyday situations. Compromise requires recognizing that there is more than one such interpretation, and that multiple interpretations can be equally valid depending on the circumstances. If you insist that there is only one valid interpretation (yours), it will never be possible to compromise.
Thanks for illustrating my point so clearly. When a liberal makes an off-hand sarcastic remark about a conservative president, you feel it's a threat that should be investigated by the secret service. But when liberals feel threatened by aggressive gun-wielding conservatives, they are just a bunch of sissies who need to shut up because its your Second Amendment right to carry around an AK-47 on a university campus.
If you really care about reaching an end to partisan intransigence, you should think about it a little bit. Trying to understand the other sides POV and compromising when necessary are critical to a functioning democracy.
Universities could use more funding, yes, but that's not really the source of the problem. Universities do basic research. A new mechanism of action for an antibiotic, for example. However, having made that discovery in an academic lab, there is a LONG way to go for it to make it to market. The short, non-exhaustive list, includes target identification, structure-activity relationship modeling, formulation, cell-based assays, pharmacokinetics and dosing, synthesis scale-up and purification, efficacy testing, safety testing, regulatory review...and all of that has to be done BEFORE it can be sent to manufacturing where there is another whole host of issues (production yields and purity, lot control, supply chain management, etc).
None of this is the domain of university-funded academic labs. Some of it might fall under the umbrella of "translational" research (aka "de-risking"), or could be covered by a non-profit group. But most of it has to be done by a commercial company. There is no other efficient way to handle such a complex product life cycle.
I'm not an anti-gun nut, unless you care to characterize yourself as a pro-gun nut. I don't care if you want to keep a gun for self-defense in your house, or go hunting, or go to the shooting range. I just don't see why you have to walk down the street brandishing a rifle claiming that it is some sort of Second Amendment right.
Anyway, they weren't "just walking around". It was an organized protest, and they were brandishing loaded guns. A person purposefully demonstrating their ability to shoot someone at any time is intimating violence. It is a warning and therefore a threat to do violence.
Interestingly, these guys were able to make their point without carrying around loaded firearms,
http://www.washingtontimes.com...
We don't have proper management. Hence the article, no?
Indeed. Well, I would say we are doing ok, but we need to do better. But finding new antibiotics without improving the effectiveness of antibiotic delivery will not likely be a sustainable solution.