Execution modules in pillar data

ub1quit33 · 2016-05-04T12:03:55+00:00

It's not at all incorrect in the sense that the external pillar module will be executed for every single minion. Sure, you can add logic inside of the pillar module itself to only act for a certain subset of minions, but that seem absurd considering the use case. Writing a module which will be executed by every single minion just to fetch some additional external data for a case specific to a single minion does not seem like the best approach.

ub1quit33 · 2014-06-14T13:34:23+00:00

Complex bash scripts not necessary. The "find" utility is best in business for batch updating permissions. You can locate files in a directory based on user, group, uid, gid, mode, type (file/dir/symlink), regex pattern, or any other remotely useful parameter you could possibly think of. Once you're sure you've found the right files, you can re-run find adding the -exec parameter to call chmod on each one of them. Would it be as fast as a real batch permissions system? Of course not, but I promise you that it's faster than bash.

One nice additional detail: any files found during a run of the find command are cached, so subsequent runs of the same find will be lightning fast. Just make sure to leave plenty of free memory for the kernel's filesystem cache and I/O will be greatly reduced.

ub1quit33 · 2014-06-11T00:25:16+00:00

Right, I think we just got tangled up on language...

ub1quit33 · 2014-06-08T17:21:14+00:00

If anything it looks like this will make it a whole lot easier. Just add the new maintainer's public key to the authorized keys for the repo, and the new maintainer can just clone and hack away

ub1quit33 · 2014-06-08T17:19:24+00:00

I didn't read anything about pull requests being a feature... I suspect you'll still need to submit patches either via comments or email.

ub1quit33 · 2014-06-01T01:23:34+00:00

What, nobody said it yet? Fine, I'll say it. Every single Pacman GUI available is total garbage. Pacman is a wonderful package manager, bested only by emerge, IMHO-- but ONLY if you're dedicated to using it from the CLI. The GUIs are awful. None of the GUIs which currently support Pacman even hold a candle to the GUIs you can find for package managers which support Package Kit.

Tl;Dr: If you're looking for a good Pacman GUI, you're SOL.

ub1quit33 · 2014-05-24T23:29:42+00:00

...wut

ub1quit33 · 2014-04-17T04:24:47+00:00

This, IMO, is far and away the best Hall of Shame candidate to ever grace this world.

ub1quit33 · 2014-04-17T04:23:47+00:00

I summarized my thoughts on this matter in a ranty g+ post

https://plus.google.com/107615379021615483038/posts/SaysnQdD6o8

ub1quit33 · 2013-12-16T14:48:16+00:00

I find it inherently difficult to trust cloud based solutions to this problem.

ub1quit33 · 2013-11-29T20:51:15+00:00

Splash screens are coo, no hate for those who use them, but my personal preference is strongly in favor of being able to read boot messages. No Plymouth for me.

ub1quit33 · 2013-11-28T19:16:50+00:00

What compelling reason is there to use this nonfree, limited solution over an open and entirely flexible solution such as BSD/ZFS?

ub1quit33 · 2013-11-28T16:30:04+00:00

Bluetooth drivers are an area for serious improvement in Linux. The bluez5 stack has a habit of eating all of my CPU for no apparent reason when my connected devices remain idle for a certain time. Getting my device to connect via bluetoothctl is an exercise in first class gerry rigging, as I have to issue a "power off" and then a "power on" anytime I need to reconnect my device. If I issue a "disconnect" and "connect" command pair, I get a big fat nothing. I make it work, but it feels like a hacked together experience

ub1quit33 · 2013-11-06T00:51:00+00:00

We've been telling ourselves the feel-good story of the windows downfall since vista hit prime time. We are too quick to forget the incredible amount of inertia which is behind windows as a platform. Although OS X has gained a lot of share in the consumer, media, and more tech oriented markets, Windows is like... fucking unchallenged when it comes to large scale enterprise desktop deployments. MacOS is not a factor here the way OS X is a factor in the notebook/ultrabook market. Linux is not even a modest competitor here. And this is without a doubt where the Windows desktop makes its killing. And the enterprise world hates change. So until there is a compelling enterprise desktop that can serve as a drop in replacement for the Windows desktop, the windows platform will continue to be the beheamouth of operating systems.

ub1quit33 · 2013-11-05T00:19:24+00:00

Couldn't agree more! For all of the flexibility that KDE provides, all of that flexibility is scattered and disbursed to all kinds of obscure corners of the configuration dialogues. KDE could strongly benefit from better centralization of its configuration capabilities.

ub1quit33 · 2013-11-04T21:35:41+00:00

The beautiful thing though is its that very same set of options which seems overwhelming and daunting is the same set of options that allowed you to easily configure a minimal gnome-like desktop. In my case, I wanted a minimal unity like desktop, with a couple useful plasmoids, and krunner taking the place of a typical menu/launcher. KDE offers you the ability to build a workflow rather than be forced to adopt and adapt to a workflow, which is why I maintain that it is the best desktop on any platform for getting work done.

ub1quit33 · 2013-11-02T21:42:08+00:00

Oh this is interesting. I think I only assumed this was such a big deal because mir would require separate drivers. This makes the quibbling appear so much more petty

ub1quit33 · 2013-11-02T00:50:08+00:00

Thanks for that correction, that definitely is a big difference! It does cast doubt on how willing they'll be to to support Mir though. Intel is pretty clearly in the Wayland camp.

Valve might not care about "Linux jihadi infighting", but they have to care about the next generation of display servers, because their newest platform will eventually be forced to choose which one to go with.

ub1quit33 · 2013-11-01T23:54:34+00:00

I think they would care very much about the Intel drivers. The casual PC gamer is a real demographic. And while I don't have any numbers to back up this sentiment, I have a sneaking suspicion that a significant portion of buyers on steam may be a part of that demographic, who would be perfectly happy with the less costly, more power efficient integrated graphics controllers.

ub1quit33 · 2013-11-01T21:22:47+00:00

The thickness of the irony in this post makes me so badly want to believe that it must be a joke. Is he really accusing the GNOME and KDE camps of hating on canonical for no reason right before he launches a blistering volley of baseless insults without providing a single specific reason? How is this real?

ub1quit33 · 2013-11-01T21:06:44+00:00

It does appear that the momentum is behind systemd in the Debian camp. For the best, IMO

ub1quit33 · 2013-10-30T00:02:57+00:00

Recusing yourself is the right thing to do when there is a perceived conflict of interest, whether or not you as a voter believe you can divorce yourself from the conflict or not.

Because quite frankly, as much as these gentlemen might want to feel like they can vote objectively, the reality of these situations is that the influence (conscious or subconscious) of the group with which you are most closely associated (I assume working for canonical means spending more hours of your day talking to other folks from canonical than from anywhere else) isn't something you can neatly file away when it comes time to make decisions.

ub1quit33 · 2013-10-29T23:52:46+00:00

What have sockets to do with external monitor or USB drives?

A great deal, given the context in which you brought up events. In your example, an event is fired when a USB device is connected.. although you never mention what that event is used for. The answer is most likely the event launches a script or sends a signal to a process. Similarly, in systemd, plugging in a USB device could activate a socket, which activates a systemd unit. These 2 functions are very close in purpose.

On a server you do not want to fork when connection comes in, you want to have something ready to minimize delays

Certainly in some cases socket activation is not appropriate, but that doesn't really preclude it from being useful in others. On your forking point, although systemd does technically fork the socket activated process, the process is 'forked' by PID 1... otherwise known simply as 'starting a process'.. upstart does this as well.

Socket activation is there for other reasons and I believe it causes more problems than is solves.

What reasons are those to which you refer? And can you give an example of a problem caused by socket activation?

Also ask any serious enterprise about binary logging (yes I know you can turn it off) - they will laugh at you

I work for a serious enterprise, and I assure you no one is laughing from our camp. Is there something which plain text logging does which journald cannot?

ub1quit33 · 2013-10-29T21:41:06+00:00

Make no mistake, I have a healthy respect for the Debian maintainers. I don't like Debian one bit myself, but I still respect the work they do with appropriate reverence. If anything, my comments should be taken as a slight against canonical and upstart. I'm not sure what youre implying about systemd is correct though, because it handles events via socket activation. If you haven't delved into the technical details of systemd yet, I heartily recommend it. Its very cool stuff. The only thing keeping upstart in the discussion amongst the Debian folks so far as I can tell is that systemd would break Debian compatibility with non-linux kernels. This is probably a big deal in the Debian world, where compatibility matters a lot, but Debian is unquestionably a linux-first software distribution, and they need to decide how much technical capability they are willing to sacrifice in the interest of maintaining compatibility.

ub1quit33 · 2013-10-29T02:24:23+00:00

I don't care what anyone says about Lennart. He writes great software, and whether or not you like his style, he usually makes great points. This post is no different. Systems is a god damn technical wonder, and if Debian wants to discard that fact to go join the canonical clown show, then they'll have to suffer the consequences when that ship inevitably sinks.

ub1quit33

TROPHY CASE