Suspicious Dish posted:

Thank you guys for the words of encouragement earlier. I went ahead and finished up my effortpost on Wayland. It's probably a bit too detailed and assumes too much knowledge, but hopefully it's somewhat readable!

http://blog.mecheye.net/2014/06/xdg-shell/

Notorious b.s.d. posted:

gtk2 is actively maintained

Notorious b.s.d. posted:

the last release was 19 days ago -- 2.24.25

that's right, they're on their 26th patchlevel of 2.24. because officially there will never be a 2.26.

Soricidus posted:

dbus-send

Progressive JPEG posted:

lamo so i just spent the last couple hours trying random poo poo to get a custom xinput keymap applied for my weird mouse: reverse left/rightclick + switch up the thumb buttons a bit
but xinput settings are dropped on the floor whenever the machine is suspended, so you have to do some extra bullshit if you don't want your configs randomly changing on you:

- all the howtos from circa 2011 recommend putting it in a /etc/pm/sleep.d script that gets called on resume, but that doesn't work because xinput wants to be run from within the X11 session and not by some random script running as root. also it seems like the mouse device isn't even listed at this point where xinput is concerned
- then some newer poo poo says to use a gnome-settings-daemon 'hotplug script' (even the example script has bad indentation lol). the script runs successfully in the logs but the settings aren't actually sticking -- something is overriding it
- maybe it's xorg itself that's overriding it on resume?? try adding a config to /usr/share/X11/xorg.conf.d (not in /etc for reasons) for the mouse. but nope that's apparently not it either, mapping is still getting stomped
- then i find some people saying to turn off a mouse plugin in gnome-settings-daemon via a manual gconf command, which likewise doesn't seem to do anything but whatever
- THEN when browsing around in there i see a gnome-settings-daemon option to switch the mouse to left-handed directly, which is half of what i want. after switching that on, the left/rightclick are suddenly reversed, now the xinput keymap that's stomping on my custom keymap is suddenly a version that's left-handed

so in short something in gnome-settings-daemon is actively making GBS threads on any custom keymaps whenever the compute resumes from suspend, in such a way that even other customization methods within gnome-settings-daemon itself are themselves stomped on

that said this is bunters lts so who knows maybe it's something canonical did

Soricidus posted:

does it have support for being used for real work yet

Notorious b.s.d. posted:

the intel linux driver is feature-complete, but really slow. everything "works" but you can't play videogames very well for framerate reasons. i got about 1 frame per second playing sc2 on linux with sandy bridge graphics. it rendered perfectly, but that was not really my concern.

the amd open source driver is reasonably featureful, but completely unusable due to speed. the closed source driver is equally slow but also so broken that nothing works properly.

if you want to play vidya games on linux, you need an nvidia chip and the nvidia binary blob.

nosl posted:

I just don't want Linux turning into GNU/systemd/linux. That would be terrible. But I've gone from hating systemd to thinking it's quite alright, but I like Linux for options. I like that if systemd starts sucking, I can install OpenRC (my favorite init, flame away, I know it's poo poo) and enjoy my slowass boot times and my preferred syntax.

pram posted:

in overlayfs, is there a way to combine the upper and lower mounts permanently?

CPColin posted:

"I want to get off Mr. Shuttleworth's Wild Ride."

"Just looking at Unity makes me feel sick."

nosl posted:

my compile flags are quite normal and not riced

I don't often do a system update unless it's been a few months, and just upgrade important packages until then. The only reason I checked the difference was because I installed a brand new processor that is supposedly twice as fast at compiling. While this is apparent for larger packages blatantly, smaller ones seem to have no major difference.

I wasn't trying to divert the ambiguous nonexistent topic, sorry for ruining your day man. Next time I'll just cut my dick off and install Ubuntu while listening to boy bands through mpd before I even consider posting something related to linux on the linux thread.

eschaton posted:

back in the day the first step really was to get and build GCC 1.x using a vendor compiler that was some degree of terrible

it actually involved bootstrapping GCC with the vendor compiler and then rebuilding GCC with itself to really get decent performance and avoid codegen bugs and the like

until 386BSD and Linux, NEXTSTEP was the only major UNIX to ship with something other than a terrible closed vendor compiler

Cocoa Crispies posted:

do linux filesystems support hard-linking directories?

Notorious b.s.d. posted:

quote:

quote:

To keep track of hard links, HFS+ creates a separate file for each hard link inside a hidden directory at the root level of the volume. Hidden directories are kind of creepy to begin with, but the real scare comes when you remember that Time Machine is implemented using hard links to avoid unnecessary data duplication.

Listing the contents of this hidden directory (named "HFS+ Private Data", but with a bunch of non-printing characters preceding the "H") on my Time Machine backup volume reveals that it contains 573,127 files. B-trees or no b-trees, over half a million files in a single directory makes me nervous.

quote:

quote:



In HFS+, all hard linked files are really pointers to "actual" files in a special directory:

/^^^^HFS+ Private Data

Those four leading carets represent null characters (ASCII 0). We call this the metadata directory. The files all have names like

iNode<nnnn>

where <nnnn> is a link number. In practice, the link number is equal to the inode number (or CNID). However, this is not required in the specification, and TSK does not assume that this is so.

In TSK (in the standard build) those null characters, and all other nulls appearing in file names, are mapped to the caret character. Thus, in printed form, you will see carets, and you may enter carets when specifying such a path name.

The HFS+ hard link is a file in the file system Catalog which is marked as a "regular" file, but has some special characteristics that indicate that it is a hard link. One of its metadata fields is a "link number" which can be used to assemble the path name to the actual file which we refer to as the target of the link. The HFS+ file system is supposed to transparently direct all references to the hard link to the target file instead. Such target files are, themselves, never hard links.

MALE SHOEGAZE posted:

looks like they got close to a nice modern looking ios UI and then hosed it up with that terrible window topborder

crazypenguin posted:

really this is because everybody is conflating orthogonal things, and of course their designs suffer as a result

docker and xdg-app are both guilty of trying to solve one problem (distributing software with the right dependencies included) and another unrelated problem (like sandboxing or separation between services) at the same time

i still dream of a day when we'll have
(a) libraries use relative paths to look up their files, instead of hard coded absolute paths like /usr/share
(b) package managers capable of managing packages in places other than root
(c) a maven-like build system that's happy to download packages to a project directory and build executables that use those instead of whatever is system-wide

it'd get us a 1000% better development environment, and give us a perfect technical solution to the dependencies problem that both docker and xdg-app (and whatever else!) could make use of.

i think it isn't even that hard to hack together a system that sort of works like this (e.g. I think the right flags will make dpkg or rpm install to arbitrary paths, rpath is enough to find libraries in different locations, making the build tool is just making the build tool and doesn't require outside buy-in) but I shudder to think of what the reaction would be if I tried to send a patch to, say, gtk to use dlinfo to figure out where to look instead of hardcoding /usr/share/whatever

but man, if only we could get everyone on board. it'd be so nice.

mike12345 posted: