Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:Not sure how that works (Score 1) 362

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.

Comment Re:Not sure how that works (Score 2) 362

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.

Comment Re:Perhaps something more complex is involved (Score 1) 325

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.

Comment Re:Who cares? I do (Score 1) 237

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.

Comment Re:Who cares? I do (Score 1) 237

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 argument on technical grounds no matter how many times they are invited really sums up the reason why so many pro-initd people get frustrated.

And here you are, again, accusing me of being rude while in the same breadth calling me (and everyone else) a fool and/or idiot, but I digress...

The primary issue is that functionality people need is there, working out of the box, with systemd. They don't have to write or customize anything themselves in non-standardized ways that no vendors will agree upon. You say all of the functionality is there with inittab+initd. Fine, let's say I believe you. Why does no distribution ship it that way? Methinks the answer is, it is not as easy as you claim. Sure, you can hack some scripts together to approximate the same functionality, but it doesn't not work well enough or generally enough to be shipped by a distribution. And that is ultimately what people want.

Incidentally, can you explain why so many people have looked at this problem and concluded they can't do it with inittab+initd? Before Red Hat's systemd, there was Ubuntu's upstart, then OS X's launchd, then Solaris' SMF. Even FreeBSD is looking at moving away from init to something more like launchd. If you're going to claim that it's because everybody is an idiot, then that's a reasoning that is pretty hard to accept.

Comment Re:I'd find a job... (Score 3, Insightful) 564

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.

Comment Re:I'd find a job... (Score 1) 564

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.

Comment Re:Who cares? I do (Score 1) 237

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.

Comment Re:Who cares? I do (Score 1) 237

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.

Comment Re:Who cares? I do (Score 1) 237

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.

Comment Re:Who cares? I do (Score 1) 237

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.

Comment Re:Linus Wins Again (Score 1) 221

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.

Comment Re:Who cares? I do (Score 1, Insightful) 237

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.

Comment Re:Who cares? (Score 3, Insightful) 237

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.

Comment Re:Distributed Hg. (Score 1) 221

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.

Slashdot Top Deals

What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875

Working...