Language:
switch to room list switch to menu My folders
Go to page: First ... 119 120 121 122 [123] 124 125
[#] Tue May 02 2017 17:54:54 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's also more stable than the Windows API. The Windows kernel is intentionally hidden behind the WinRT/Win64/Win32/etc. API family, so MS feels more freedom when it comes to tweaking kernel APIs. Linus mandates that user-land applications from 0.99 kernels are able to still run on 4.11 kernels, so actually has a better track record of compatibility than Windows from that particular aspect.

[#] Wed May 03 2017 16:22:10 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


As someone who still uses Windows 10 for games but also does development work for a living, I'm really quite excited by all this.

[#] Wed May 03 2017 20:48:49 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I am too; it really makes everything a little more accessible.

At the same time, now that I have two well-powered laptops, I can have the best of both worlds. I just installed Kubuntu on one of them and am realizing how much I missed having a native Linux around. KDE is looking good these days. For a while it had too much of a eurotrash thing going, but they've cleaned it back up. I like how they make it look and act like an actual desktop, instead of pretending to be a phone or a tablet.

I figured I'd go with KDE this time because it's the native environment of my very favorite video editor on any platform: Kdenlive.

[#] Thu May 04 2017 07:34:38 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I wonder, sometimes, how people manage to make interesting debian packages at all.

There's this thing called debconf that one ought to use for asking the user things like the password to a database engine so you can add a new database and tables, etc. And there are these commands with which you may littler your postinst scripts to drive this kind of thing.

But you aren't likely to find the documentation for these commands easily.
No. On the official debconf site, they claim that because these commands are now part of Debian policy, you have to find them there. So you try to find them there, and you're treated to a byzantine labyrinth of text, hinting of the promised text without offering it to you easily.

I wonder how many people would use this system, but give up and just use bash's 'read' instead because fucking hell, you can at least find documentation for bash.

[#] Thu May 04 2017 15:20:05 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(raises hand.)

[#] Fri May 05 2017 06:29:10 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I did, eventually, figure out what I needed, following debian policy, etc.

But, sincerely, those guys ought to make the documentation a tad less dense, and a bit more streamlined for the guy in a hurry.

Basically:

* Redirect all stdout to a file, so you can refer to it later if something fucks up.
* You might also want to redirect stderr there, too.
* Output nothing to the user at all, short of something on stderr telling the user where to find this output.
* Use debconf commands for the rest. If you're using sh or bash, they start with db_, and you have to run their script to make the commands accessible.
* Remember to write a lot of echo statements into your log file so you can figure out when something fucks up. Because debconf sometimes just seizes up the whole damned script when you set -e at the top of the script (per policy) and something decides to go wrong.
* Test the fucker until your eyes bleed.

[#] Fri May 05 2017 06:32:05 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Oh, the actual prompting happens within config, not postinst. But if you used db_reset to kill off the password (like you should), and you need it again on uninstall, you'll need to reproduce whatever you wrote in config in your prerm script. Or, be sneaky like me, and simply call config from prerm.

I have to say, it all does look very clean and slick when you use debconf, but the documentation leaves much to be desired.

[#] Sat May 06 2017 14:01:47 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

the best of both worlds. I just installed Kubuntu on one of them and

am realizing how much I missed having a native Linux around. KDE is

And I'm really liking this. KDE 5 looks and acts like a desktop.

I just dropped my Linux laptop into the dock (which fits both of my laptops) and it picked up *everything* without requiring any configuration. Multiple monitors, multiple audio devices, multiple network interfaces, it's all there, no fuss, no muss. And it looks fantastic.

I'm tempted to make this my daily driver for a while and see how it does at the workplace. In the meantime it's going to stay in the dock all weekend.

[#] Mon Jul 31 2017 17:34:46 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I'm in systemd hell...

[#] Mon Jul 31 2017 21:46:27 EDT from zooer @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Did you try turning it off and back on again?



[#] Tue Aug 01 2017 05:59:23 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Gah... I wish you luck with that, LS.

[#] Tue Aug 01 2017 11:24:49 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

systemd, upstart, init....

Personally I'm with the Boycott Systemd folks - it goes against basic Unix philosophy.

[#] Tue Aug 01 2017 12:36:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Looks like that horse has left the barn.


Things don't seem to be working the way I expect, but maybe my expectations are wrong. I have to read up and test a bit more.

[#] Tue Aug 01 2017 15:44:59 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I suppose it's unsurprising that some of systemd's APIs have Haskell bindings... *vomit*

[#] Tue Aug 01 2017 17:42:55 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've been pretty happy with systemd, but it is true that systemd (like upstart, which fortunately is dying, and launchd, which unfortunately is not) is somewhat less "unix-like" than sysvinit.

The thing about systemd is that it *has* an API. And to install a service you only have to create a single unit file, and then make an API call (or just run the equivalent command from a shell script) to activate it. sysvinit is more understandable from a traditional unix perspective, but unfortunately it's a mess.

Of course, I never really liked init scripts to begin with. /etc/rc was better. (Yes I know slackware and BSD still use /etc/rc and I don't care.)

[#] Tue Aug 01 2017 18:05:27 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Binary logs? Blech.

[#] Wed Aug 02 2017 02:25:48 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Contrary to historical indications, the 'd' in systemd does not stand for daemon. It stands for disease.

[#] Wed Aug 02 2017 11:48:58 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Well, as I understand things (with my horribly Windows-esque background), sysvinit has this terrible problem where the scripts cannot be started concurrently.
So, we have two attempts, so far, to create something that can sanely start these services, yet still feel 'unixy-enough' to please people... and I guess from what I'm reading here, they both fail.

I think I prefer systemd to upstart... it feels more featureful, and I think it's slightly easier to write configuration files for it than upstartd (maybe because it's better documented? I forget).

I know that I've had to write scripts for installations that account for all three systems, and systemd felt more mature than upstart in this regard.

I think another problem I experience with sysvinit involves the many variations per distribution of linux of any kind of helper script to get things running.
Basically, if you're trying to write something that can be installed on Redhat, Debian, and variants of these, sysvinit risks introducing a lot of pain unless you build the entire thing from scratch without any assisting batch scripts.... and if you do that, you might miss some special thing that the distribution does that helps inform the user of some detail or something.

Or, putting all of this more concisely, the initialization of services in Linux is very problematic without *something*, while Windows (much as I hate it) with its SCM seems to have happened upon a fairly (for Windows) elegant solution. It'd be nice if someone could figure out something for Linux that felt right for posix-oriented OSes.

[#] Thu Aug 03 2017 17:48:21 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


the point about mission creep might be valid; I don't really know why they decide to make another logging service where we already had syslog.

[#] Fri Aug 04 2017 00:34:05 EDT from kc5tja @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That is a bullshido response if I'd ever seen one. Systemd is a total slap in the face, and completely ignores a TON of prior art in improving or even replacing sysvinit with alternatives that work as well, while retaining the Unix-y flavor.

BTW, Windows has a ton of supporting "batch" scripts as well (MS Installer anyone? OK, they're not literally .BAT files, but they do the same job) which gets executed upon installation or removal of a program. The only benefit to Windows is that you have one, and exactly one, precise directory layout.
But this is a solved problem in Linux, and has been for years.

Meanwhile, systemd seems to be a literal breeding ground for CVEs and bugs (DNS daemon that can't handle dashes? Sure. Why not?)

Systemd works great until it doesn't, then you're left in a world of pain and suffering. For cloud deployments, which is where systemd really shines, it works great because you have (like Windows) consistent system configurations.
But for anything else, it's a catagorical mistake.

Go to page: First ... 119 120 121 122 [123] 124 125