|
why oh why is this not the default? of course, this doesn't help me since i'm using unity. anyway, as a desktop linux user of 10 years, alt-tab is probably the thing I hate the most right now. one the one hand, that seems spoiled, since it used to be poo poo like having to compile audio drivers from source. on the other hand, this hits me multiple times EVERY DAY ARRRHGH
|
#
¿
Jul 23, 2014 23:31
|
|
|
|
| # ¿ Apr 28, 2024 11:23 |
|
|
I thought ubuntu phone was dead after that kickstarter or whatever it was, where everyone responded "we don't want that, wtf"
|
|
#
¿
Aug 18, 2014 17:58
|
|
|
Suspicious Dish posted:I recently showed the maintainer of nautilus about "perf top", and he spent his whole weekend fixing performance issues in nautilus. This next release will likely be much faster.  I already thought perf was awesome for getting flamegraphs of both apps and the whole system, and now i've only just discovered perf topperf is magical
|
|
#
¿
Sep 12, 2014 18:27
|
|
|
eschaton posted:for example, having pid 1 have anything to do with locale is just silly, that should be per-user Just picking this as an example. The user locale is per user. The question is the locale for system services. Sysvinit has every single init script set it themselves. Most distros have settled on requiring all init scripts to source another one that sources another one to set it before they do anything. Systemd has two points of interest: the first is a separate binary and dbus service for the sysadmin to get/set the system locale. The second is during first boot, where it actually gets set "omg in pid 1". Its 48 lines of code. Opens /etc/locale.conf and sets environment variables. And of course, if services want to set it themselves they still can. This design seems sound. I don't know why the dbus service is necessary (paranoid forward compatibility perhaps), but it's existence should hardly be upsetting.
|
|
#
¿
Nov 23, 2014 18:18
|
|
|
Soricidus posted:I've never gotten the obsession with horizontal panels. our monitors are getting wider and shorter, surely the only logical thing to do is to shift to taking up space at either side instead agreed. something unity actually gets right. I might even actually like unity if they hadn't inherited the alt-tab alt-` crap from gnome 3, and then also not had any good way to fix it, unlike gnome 3's extension.
|
|
#
¿
Feb 16, 2015 17:22
|
|
|
Subjunctive posted:tbf, browsers and code editors are unusual in the breadth and scale of their demands on a widget toolkit. I understand browsers, but what do you mean about code editors?
|
|
#
¿
Feb 16, 2015 21:26
|
|
|
Suspicious Dish posted:hi thread, today i got chewed out by an extremely unstable developer in the foss graphics space I saw that on p.fd.o yesterday and thought about posting it here. then i looked into it way too much and decided it was just sad.  as near as i can tell, ages ago he wrote an open source ati driver, then some other people wrote a different ati driver for some reason, and their's won. and it broke him? i can't even point and laugh at that. that's just someone is real need of therapy. sucks it doesn't sound like he's getting any.
|
|
#
¿
Apr 24, 2015 16:27
|
|
|
Suspicious Dish posted:wouldn't it be cool if you could ship your own binaries, since you're the application author and you sort of know how these things should be made i was really happy when Linus bitched about this at debconf. of course, the result has been fuckall happening. the only movement I've seen on it was that stupid idea to use containers. hey guys, instead of making our software not suck and assume hard paths like /usr/share/gtk, let's just containerize everything and download gigabytes to make each individual desktop app work. totally great idea.
|
|
#
¿
Jun 23, 2015 20:44
|
|
|
Suspicious Dish posted:nobody thinks this did I misinterpret this? http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html quote:In the example above, we have three vendor operating systems installed. All of them in three versions, and one even in a beta version. We have four system instances around. Two of them of Fedora, maybe one of them we usually boot from, the other we run for very specific purposes in an OS container. We also have the runtimes for two GNOME releases in multiple versions, plus one for KDE. Then, we have the development trees for one version of KDE and GNOME around, as well as two apps, that make use of two releases of the GNOME runtime. Finally, we have the home directories of two users. To me that sounds like Firefox gets developed against Fedora, so to install firefox under this scheme on debian or whatever, first download an entire fedora OS image. maybe the idea is that apps will only depend against runtimes or something?
|
|
#
¿
Jun 23, 2015 21:48
|
|
|
okay, yeah, it looks like runtimes as the only deps for apps. hmm, maybe this is alright, except for the btrfs bit. that's still a completely stupid pile of crap just to work around hard-coded paths in shared object files. 
|
|
#
¿
Jun 23, 2015 22:14
|
|
|
i don't think so, it's really about paths. the trouble is that we currently do things like name a package "gtk-2.0-0" and thus it owns that name under /usr/lib and such, even though its gtk 2.20.1-ubuntu6. skipping the runtime stuff and just talking packages, if we installed everything to, say, /usr/pkg/gtk/2.20.1-ubuntu6/{bin,lib,include,share}, then that could co-exist with any other version including -ubuntu7 just fine. all our troubles stem from wanting one thing to own the name "gtk-2.0-0" in /usr/lib and one package putting its data under /usr/share and so on. and this btrfs approach is ignoring and not fixing that problem, and just heaping more abstraction layers on instead. Suspicious Dish posted:Note that we're really pushing xdg-app as the real implementation, which doesn't use btrfs. I don't know if Lennart is still pushing his btrfs system. I'll put it on my todo list to check out. haven't seen anything about it yet. thanks.
|
|
#
¿
Jun 23, 2015 22:46
|
|
|
from the xdg-app page:quote:A runtime provides a well-defined environment that an app can run in. Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr. this is exactly what I was initially afraid of. how is this not essentially going to be an os per application if it's providing all of /usr?
|
|
#
¿
Jun 23, 2015 22:56
|
|
|
evol262 posted:And you expect the linker to resolve this sanely how? Explicit -ubuntu7 names? Packaging binaries in /use/pkg/ubuntu7/bin you'd use the normal, existing so names. it's perfectly possible already for rpath to do this sensibly already. App bundle binaries use rpath to look things up locally, and locally are symlinks to the correct so files in the correct packages. so basically under /usr/pkg/yosposbithc/1.0.0/lib/libgtk-2.0-0.so -> /usr/pkg/gtk/2.20.1-ubuntu6/lib/whatsever.so. so at install time, the correct dependencies are installed, and the correct symlinks created to the exact package version, and then it's just a normal program you just run. no env vars, no container setup. just a program.
|
|
#
¿
Jun 24, 2015 02:44
|
|
|
evol262 posted:Way, way better than trying to work out some kind of modern, maintainable method of deploying applications. *shrug* I disagree. I think this is the maintainable way. the basic point is to just fix libraries so that multiple versions can be installed at the same time, by fixing them all (and probably adding a new feature to ld.so) to use relative paths to find their associated data. on top of this, just about any "install an application that wants specific versions" scheme at all can be implemented.
|
|
#
¿
Jun 24, 2015 15:09
|
|
|
okay, so I've looked at xdg-app a bit more, instead of doing real work. I'm more convinced it's a good idea, but it still has a couple critical flaws. First, this is a system for writing sandboxed "gnome apps" or "steamos apps" not for writing "linux apps". Or at least, this is the only way the runtime approach doesn't become a clusterfuck. I imagine there'll probably be only like 3-6 major runtimes (prob. steam, rh, ubuntu, gnome, kde in decreasing order of my expectation that they'll actually succeed at maintaining ABI compatibility) however, writing "gnome apps" will be like writing "android apps" in the sense that this is very very much not writing ordinary linux programs. the xdg-app devs talk about firefox and libreoffice in their high-level future examples, but I don't think these apps will ever fit well into the runtime model. possibly they could be forced to fit in, but nobody will be happy and there will be more unruly things, like python or sublime text and so on that still refuse to fit. These app developers don't want to be put into the position of "oh, now you have to choose sides in the desktop wars, pick the gnome runtime its the only sensible choice you heretic." So instead of vendors providing apps that work on any distro, it'll be gnome devs wrapping firefox for the gnome runtime, so you can install it in yet another still not from the vendor way that's pretty much a distro within another distro. however, I think it'll be a great system for, like, linus's dive log program or i dunno, evemon. just pick gnome runtime who cares and boom, it works on all distros. great. Second, I think bind mounting custom /usr for the runtimes is a technically inferior approach compared to using rpath together with libraries that aren't broken (due to absolute paths.) It solves the problem just as well, and it's adaptable to making it possible to install "linux apps" from vendors regardless of distro in a much more general and useful way than the runtime concept. it also makes my life easier as a developer, as I can much more easily develop against versions of libraries are aren't installed system-wide
|
|
#
¿
Jun 24, 2015 23:23
|
|
|
eschaton posted:let me tell you about this great compiler flag -isysroot yeah, it's not enough. now I need to run things, not just compile and link. now what about those libraries having hard coded paths to /usr/share and not finding their data? and of course, there's still the "how do i distribute this to users" which was really the main topic
|
|
#
¿
Jun 25, 2015 14:56
|
|
|
Notorious b.s.d. posted:they picked the unix bindings as defaults long ago, and all the windows shortcuts are workarounds do they document these workarounds somewhere? like, why does alt-# not work on windows?
|
|
#
¿
Aug 24, 2015 18:56
|
|
|
Notorious b.s.d. posted:i want your software to be in the package system we could have had this ages ago, and we probably still will get it... eventually. I think the problem is distro devs who have an irrational hatred for "bundling". I mean, the kind of thing you mention is a solution to concerns about bundling, but you see, if we attempt to build the infrastructure to support such a thing, those drat users might use it to do bundling!! this always struck me as a real-world equivalent of "spider? burn the house down!" and I think it's had a disastrous effect on linux in general.
|
|
#
¿
Nov 9, 2015 22:40
|
|
|
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.
|
|
#
¿
Dec 21, 2015 21:29
|
|
|
Notorious b.s.d. posted:it's a "solution" that creates more problems than it solves. *shrug* disagree. "don't touch poo poo that belongs to the package manager or things break" is pretty simple imo. who... just moves binaries around? this sounds like bad sysadmining practice from 20 years ago. quote:the correct solution is the solaris/SVR4 way: very much disagree. 100% of my point is that system-wide installations are not the most important thing at all. developers need different configs to work on different software and developers shouldn't need to be root to get the libraries they need either
|
|
#
¿
Dec 22, 2015 18:48
|
|
|
Notorious b.s.d. posted:if it's managed by the package manager, library paths are known in advance and relative paths offer no advantage but with a package manager that can handle multiple installations in addition to system. like a lot of language package managers (e.g. i might install to /home/crazypenguin/repos/myapp, which wouldn't be known in advance to package builders and there'd be a nice .apt or something directory in there with all the package metadata) anyway, also: maven-like build tool makes packages, not binaries. if you want to install it into your path, you'd have the package manager install the package.  quote:the industry is trending exactly the opposite direction of your preferences yeah, i know :/ complaining that containers seem like a big rube goldberg machine to work around the fact that packages always expect to be system-wide is why i started blathering (not that containers don't also have other legitimate purposes, of course. but i think the design of docker, etc suffers because they're also being used as dependency management. i think docker would be a lot better if *the* standard way to create a container was "this .deb here" and it makes a container out of it and its dependencies, no additional fuckery)
|
|
#
¿
Dec 22, 2015 19:27
|
|
|
i don't think libssh is used by anything important. okay, i decided to actually look at a reverse depends in ubuntu. only non-esoteric thing on there is kde, lol.
|
|
#
¿
Feb 24, 2016 19:14
|
|
|
Wheany posted:... that works in the terminal, i mean why do people want editors in terminals, i dont get it
|
|
#
¿
Mar 9, 2016 19:44
|
|
|
Wheany posted:some times you just have to use a terminal i am actually sorta serious with that question. the only time i can think of when i use an editor in a terminal is when i'm writing a git commit message that's too long to -m. i'm pretty sure it opens nano by default. it works fine for that. I can't be arsed to try to use something different because there's issues with notifying git when I'm done editing. like, it waits on a pid and that doesn't always work with gui editors or something. is it just that you're trying to edit files that are on a remote machine, and you don't have any good options for being able to slurp those files across ssh in order to use a good editor? ...i wonder if i can fix that
|
|
#
¿
Mar 10, 2016 00:07
|
|
|
I tried out 16.04 for about 5 min. Gedit didn't have menus. At all. I gave up.
|
|
#
¿
May 2, 2016 15:07
|
|
|
i'm suspicious of docker, but kubernetes looks really good and they're built on docker, so idk
|
|
#
¿
May 2, 2016 19:13
|
|
|
Celexi posted:LMAO after thinking about it a bit, i've decided this is only a little bit dumb dumb #1: break things every two years? wtf? 5+ years, maybe. take some time to think, gently caress dumb #2: they have no credibility that they'll properly maintain the 3.x line when 4.x is out. if I thought they'd release gnome 4 and have it come with 3.30 and 4.0 both 100% supported and properly maintained as first class citizens with no "we're not working on 3 anymore because 4 is the future" bullshit, it'd be a good strategy. It'd be kind of how like python 2->3 sucked less once they started backporting things from 3 to 2 that had no business being held hostage. They can dogfood 4, while honestly recommending 3.30 to 3rd party stuff. but every 2 years come on. expect 3rd party apps to take 10 years to upgrade to a new gtk. they're not seriously proposing supporting 5 versions, so they're proposing saying "gently caress you" to their users.
|
|
#
¿
Jun 14, 2016 17:48
|
|
|
ahmeni posted:kubernetes looks good but loving Google product lifespans kubernetes looks amazing, and I wish I could use it, but it scales down poorly i suspect it'll live though. supposedly it makes money in their cloud stuff, and there's multiple companies working on it.
|
|
#
¿
Jun 28, 2016 19:50
|
|
|
I'm not sure I quite get what you're saying. You're not advocating running chef inside your containers on a kubernetes cluster are you?
|
|
#
¿
Dec 2, 2017 21:51
|
|
|
That makes sense, but it doesn't seem to me like that's what nbsd said. Maybe it's me though.
|
|
#
¿
Dec 2, 2017 22:00
|
|
|
Notorious b.s.d. posted:you are likely to run it exactly once, yes. The whole entire philosophy behind things like kubernetes is that the container is an artifact. Your build process produces the container. If you want to update it, you run a new build that produces a new container. It doesn't matter if your build process is some garbage made of spit, chewing gum, and duct tape. It's just a build process. If it fails, you get a bad container or no container. Your CI says "poo poo's hosed" and you fix things. Deployment never gets touched. The problem with shell scripts to manage deployments is they're fragile as gently caress. That's what things like Chef are meant to fix: doing better than "if you happen to be in the expected state, and run these commands, you'll hopefully end up with a good state if nothing unexpected went wrong ,and if so, haha you're hosed good luck production is down lol" (edit: well, and also the point is to make sure your configuration is written down as code, and not just whatever state the machines happen to be in, but that's besides my point here, because both approaches do that fine.) The whole point of containers is that doesn't happen anymore. It doesn't matter how you build them. But running chef inside a container undermines that. It's a much worse way of doing things. I'm not sure why you're being so mean to this guy. crazypenguin fucked around with this message at 21:20 on Dec 3, 2017 |
|
#
¿
Dec 3, 2017 21:18
|
|
|
jre posted:I've not seen anyone suggesting running chef in a container ? nbsd did in the post I quoted.
|
|
#
¿
Dec 3, 2017 21:34
|
|
|
if I understand things correctly: 1: the root of the problem is that 32-bit arm hardware can have (probably) 8 byte RTC, but the linux arm32 ABI has a 4 byte time_t. 2: this means the hardware and kernel can both agree it's 2120, but userspace will bug out. 3: systemd tries to detect time changes by setting a timer for maximum time_t, which seems reasonable, but the above means this could be in the past (2038) according to the system clock and so immediately fire. But the clock isn't looping around when it reaches max time_t, so it's immediately firing always forever in a loop. So that's the root cause: the kernel can think of times beyond what userspace is capable of communicating to it. This is a real problem with the arm32 arch on linux. So a fix for the root cause would be for arm32 to have an 8 byte time_t. This would probably be an ABI break? I dunno if they'll do it? So poo poo's probably hosed. lol how did they go about upgrading time_t for 32 bit x86? or did they
|
|
#
¿
Jan 2, 2018 23:21
|
|
|
it's really annoying that tpm & secure boot, the best things to happen to desktop security until widespread sandboxing started happening, are ignored by most linuxes because of bullshit conspiracy theories about microsoft/mpaa or whatever
|
|
#
¿
Apr 6, 2018 16:59
|
|
|
fwiw, selinux is a confusing design. Red hat has figured out how to make it work pretty well, but it's pretty much a bunch of well-engineered workarounds for a crummy core design. containers are a lot more friendly. Instead of writing a policy that says nginx can only read things labeled for it, and writing a tool that'll easily relabel /var/www for you, you just only mount /var/www inside the nginx container. way simpler to understand, even easier to get right.
|
|
#
¿
Apr 30, 2018 19:04
|
|
|
Notorious b.s.d. posted:you know nothing in here is true right. if you compromise nginx badly enough inside a container, you compromised the entire system. an lxc container is just an enhanced chroot: as soon as uid=0, you are no longer restricted to the chroot. nah, I'm right. "containers" have a fantastic security story, depending on what you mean by "containers". because of course, the linux kernel has no concept of a container, you build a container abstraction out of all the little parts. the same little parts are used to e.g. sandbox chrome processes. they're very much meant for security here. but what you say is absolutely untrue for, e.g., docker containers. if you believe otherwise, here's a root shell in a docker container: https://contained.af/ capture that flag
|
|
#
¿
May 1, 2018 03:37
|
|
|
TimWinter posted:Wasn't the last docker breakout in October? there was a recent thing involving CAP_NET_RAW, that might have been it. wasn't really a root escalation though most of the time, when actually trying to use containers for security, that capability is removed too. its left on by default because they like being able to ping from containers to help people debug, heh like, the linux kernel is a big attack surface sure, but that's true for both containers and selinux, and containers routinely cut down the attack surface a lot with things like seccomp restricting syscalls, too...
|
|
#
¿
May 1, 2018 05:35
|
|
|
I really don't get the networking complaint about wayland. Xwayland is right there and not going away? like, if you take a look at modern graphics hardware, any idiot with two braincells can see the benefit of driving it locally instead of over a network. So... separating out the two different things into two different pieces of software sounds like plain old good design? feedmegin posted:And the requirement for those weirdos who have it is met by X11 on Wayland. The onus is on those weirdos who have that requirement to argue as to why it should become a core part of Wayland. Like, nevermind the weirdos part. Even if we were all 100% convinced we needed network transparency here, a good local graphics hardware stack design plus a separate network transparency service design would be the sensible way to implement it!
|
|
#
¿
Feb 11, 2019 22:04
|
|
|
Tankakern posted:has anyone looked at that new io_uring thingie that axboe added in 5.1? haven't had a chance to try it out yet, but soooo glad we're finally getting something like it linux finally has usable async file I/O, lol
|
|
#
¿
May 12, 2019 01:04
|
|
|
|
| # ¿ Apr 28, 2024 11:23 |
|
|
Sapozhnik posted:the gold standard for this sort of key generation is to consider /dev/urandom to be of insufficient quality and requiring that /dev/random be used. and for what it's worth, I think the best crypto people keep telling everyone to stop saying this, urandom is fine for everything, and random is dumb paranoid garbage and not in the good way.
|
|
#
¿
Jun 10, 2019 02:40
|
|