|
zenith POS
|
#
?
Apr 27, 2015 20:41
|
|
|
|
| # ? Jun 4, 2024 19:31 |
|
|
Shaggar posted:no it doesn't. I have plenty of documents modern versions of office won't even read any more
|
|
#
?
Apr 27, 2015 20:54
|
|
|
Captain Pike posted:I wrote all of my college papers in QuarkXPress. I know people who used FrameMaker for all of their papers and were quite happy honestly wish I'd picked up a copy for Mac at the time, before Adobe got their hands on it and strangled it to force everyone over to InDesign
|
|
#
?
Apr 27, 2015 20:56
|
|
|
CPColin posted:The best part of my resume-building experience happened when I installed TeXstudio and its package didn't bring in any of the necessary dependencies for it to be able to generate PDF files. Then the UI have useless messages and nothing ever suggested installing the extra packages until I'd Googled it for an hour. html+css with a print layout is the pro way to do a resume in 2015 but i am better at latex than css. if you think latex is user hostile, boy howdy do i have a 21st century layout tool for YOU!
|
|
#
?
Apr 27, 2015 21:20
|
|
|
eschaton posted:I know people who used FrameMaker for all of their papers and were quite happy after the advent of hypertext documentation, framemaker was pretty much only good for academic things. it did well at footnotes/endnotes/biblio tracking + it handled really long documents well i think its original non-academic market was vendors preparing documentation in book form, and that's just not a thing people care about anymore. so what if the printed edition has lovely layout, the canonical docsets are online.
|
|
#
?
Apr 27, 2015 21:22
|
|
|
just use troff noobs
|
|
#
?
Apr 27, 2015 22:03
|
|
|
 
|
|
#
?
Apr 27, 2015 22:04
|
|
|
pram posted:just use troff noobs Scoff if u troff
|
|
#
?
Apr 27, 2015 22:06
|
|
|
use illustrator and make something that isn't ugly as poo poo
|
|
#
?
Apr 27, 2015 22:06
|
|
|
i like writing manpages in troff i think my ability to recognise good user interfaces might be broken
|
|
#
?
Apr 27, 2015 22:19
|
|
|
Notorious b.s.d. posted:after the advent of hypertext documentation, framemaker was pretty much only good for academic things. it did well at footnotes/endnotes/biblio tracking + it handled really long documents well that was its original market, but it adapted pretty well and quickly to the modern world of hypertext documentation because of the way it encouraged working with structure instead of formatting. you could build large interlinked documents and produce them one way for print, a different way for online help, a different way for online reference, etc. products like QuarkXPress and InDesign are even worse for that because they're entirely about print-targeted formatting.
|
|
#
?
Apr 27, 2015 22:22
|
|
|
pram posted:just use troff noobs just use Symbolics Concordia
|
|
#
?
Apr 27, 2015 22:29
|
|
|
Soricidus posted:i like writing manpages in troff 
|
|
#
?
Apr 27, 2015 23:00
|
|
|
im installling gentoo in my car so it can go faster
|
|
#
?
Apr 27, 2015 23:28
|
|
|
bobbilljim posted:im installling gentoo in my car so it can go faster What c flags u use?
|
|
#
?
Apr 28, 2015 01:47
|
|
|
bobbilljim posted:im installling gentoo in my car so it can go faster Fun roll loops?
|
|
#
?
Apr 28, 2015 01:48
|
|
|
SYSV Fanfic posted:What c flags u use? -Ofast, car goes faster -0g, better handling -mtune=500hp
|
|
#
?
Apr 28, 2015 01:54
|
|
|
unsurprisingly, kdbus wasn't included in 4.1. greybeards apparently fear it because it reminds them of systemd.
|
|
#
?
Apr 28, 2015 19:07
|
|
|
Zom Aur posted:unsurprisingly, kdbus wasn't included in 4.1. greybeards apparently fear it because it reminds them of systemd. also the fact that the main justifications behind kdbus being included are bullshit, esp with regards to performance. see http://article.gmane.org/gmane.linux.kernel/1939166 http://article.gmane.org/gmane.linux.kernel/1939022 systemd is good and the "greybeards" opposing it do need to gently caress off, but the linux userland crew is seriously amateur-hour compared to the kernel developers a lot of the time and it's good to see them being called out on it "userspace dbus is slow! include kdbus in the kernel so it can go faster!" "did you profile it and rigorously identify bottlenecks that can only be alleviated with new kernel primitives?" "yeah here you go" "no you didn't this test suite is crap" "no it isn't" "gently caress off and stop wasting our time please"
|
|
#
?
Apr 28, 2015 19:16
|
|
|
Mr Dog posted:also the fact that the main justifications behind kdbus being included are bullshit, esp with regards to performance. see one guy especially seemed to argue that if this was accepted in the mainline he'd be forced to use it, since other programs would start depending on it, and he didn't like that. i'm not a technical guy, and i haven't read much about this. just got the impression from this thread that kdbus might be something really good.
|
|
#
?
Apr 28, 2015 19:23
|
|
|
put everything in the kernel
|
|
#
?
Apr 28, 2015 19:28
|
|
|
idk kdbus is reminiscent of a few other lovely experiments from linux's awkward teenage years like khttpd and devfs usually when somebody says that a new kernel primitive is required for high performance another person quickly comes along and does a better-optimised userspace solution to the problem. the existing kernel socket and ipc mechanisms are really really really fast, you just need to use them correctly. the other arguments do hold water though, e.g. having dbus available straight from early boot without having to do a bunch of crazy gymnastics to make poo poo work.
|
|
#
?
Apr 28, 2015 19:32
|
|
|
They're not entirely bullshit, but the full context hasn't been properly explained. The userspace dbus server is much slower than it should be. We're all aware of this. We could spend time rewriting the userspace daemon (and Collabora did do this for GENIVI at first before hitting the context switching issues and writing AF_DBUS), but that doesn't provide us with the security benefits, availability in early boot, or cross containers APIs. kdbus solves all three at the same time.
|
|
#
?
Apr 28, 2015 19:33
|
|
|
Mr Dog posted:"userspace dbus is slow! include kdbus in the kernel so it can go faster!" "Can we try to understand why it's so bloody slow before thinking about merging something that might ossify it?" ossify is a really good word choice. once kdbus is merged it won't be free to change its interface very much or very quickly.
|
|
#
?
Apr 28, 2015 19:33
|
|
|
they're doing a good job of looking like amateurs then ("hey let's optimise this poo poo without profiling first" is really amateur hour), perhaps they need to show their working (we tried optimising the userspace dbus server, it quickly hit a wall) torvalds and lutomirsky make more compelling points than the kdbus squad, at least in that performance discussion
|
|
#
?
Apr 28, 2015 19:35
|
|
|
Tankakern posted:all my gentoo machines also run systemd
|
|
#
?
Apr 28, 2015 19:37
|
|
|
Mr Dog posted:they're doing a good job of looking like amateurs then ("hey let's optimise this poo poo without profiling first" is really amateur hour), perhaps they need to show their working (we tried optimising the userspace dbus server, it quickly hit a wall) Right, because you haven't been aware of the previous attempts that still failed. kdbus is an opportunity to fix a bunch of other issues along with performance.
|
|
#
?
Apr 28, 2015 19:44
|
|
|
The client test case is also pathologically bad, in that it does start up a new main loop with every sync DBus call because he forgot to put one in the program. In my opinion we probably should have made this a failure, but simply doing g_main_context_push_thread_default(); in main gets me a 2% speedup and all the eventfd / close is gone.
|
|
#
?
Apr 28, 2015 19:51
|
|
|
Suspicious Dish posted:The client test case is also pathologically bad, in that it does start up a new main loop with every sync DBus call because he forgot to put one in the program. In my opinion we probably should have made this a failure, but simply doing g_main_context_push_thread_default(); in main gets me a 2% speedup and all the eventfd / close is gone. <troll>yeah glib is a bloated mis-designed piece of crap, so what else is new</troll> and uh 2% is noise. this current stack is "three orders of magnitude" slower than it should be. like the kernel devs said, passing a message in userspace dbus should require four context switches: send from sender, recv on dbus-server, send on dbus-server, recv on receiver, not 17 or whatever the gently caress it was plus a whole shitton of heap churn (and associated ravaging of the dcache) kernel stuff is faster because the kernel developers actually have meaningful review standards, not because it's inherently faster by being in the kernel Sapozhnik fucked around with this message at 20:11 on Apr 28, 2015 |
|
#
?
Apr 28, 2015 20:09
|
|
|
Zom Aur posted:unsurprisingly, kdbus wasn't included in 4.1. greybeards apparently fear it because it reminds them of systemd. there were also a few legitimate criticisms about it collecting metadata (like the command line) that could have privacy and security implications. "but it's not exposed by default and someone would have to be a lovely programmer doing dumb things to use this" "exactly. if it's available someone *will* do something they shouldn't with it. rip it out."
|
|
#
?
Apr 28, 2015 20:11
|
|
|
Suspicious Dish posted:availability in early boot Not trolling: why is this necessary and what is the current workaround? To me, early boot sounds like something that should change basically never, so even if you have to put in a lot of extra effort, that's OK, if it saves on complexity in the overall design.
|
|
#
?
Apr 28, 2015 20:12
|
|
|
Athas posted:Not trolling: why is this necessary and what is the current workaround? To me, early boot sounds like something that should change basically never, so even if you have to put in a lot of extra effort, that's OK, if it saves on complexity in the overall design. early boot requires ipc just like everything else does. by "early boot" we mean initramfs. this typically runs systemd, which then launches enough services to make / mountable, then pivots root to the real root and passes control to the real systemd. this process is run in reverse for system shutdown.
|
|
#
?
Apr 28, 2015 20:14
|
|
|
fun fact: pivot_root is a normal binary invoked by shell scripts /sbin/pivot_root --help Usage: pivot_root [options] new_root put_old Options: -h, --help display this help and exit -V, --version output version information and exit For more details see pivot_root(8).
|
|
#
?
Apr 28, 2015 20:16
|
|
|
Mr Dog posted:early boot requires ipc just like everything else does. by "early boot" we mean initramfs. this typically runs systemd, which then launches enough services to make / mountable, then pivots root to the real root and passes control to the real systemd. this process is run in reverse for system shutdown. Why does this need IPC?
|
|
#
?
Apr 28, 2015 20:18
|
|
|
why does anything need ipc man
|
|
#
?
Apr 28, 2015 20:25
|
|
|
Mr Dog posted:why does anything need ipc man No, I mean, IPC is useful when you have loosely coupled changing components and all that jazz, but early boot and shutdown seems like pretty solid unchanging processes, is all.
|
|
#
?
Apr 28, 2015 20:27
|
|
|
I have a use case for this: plymouth. The boot splash right now wants to be able to take hold of the DRM FD, but then drop it after the display manager comes up. logind already has a great DRM negotiation API. I'd like to reuse it instead of building our own handshake system. For reference, "early boot" means "from the beginnings of the initrd up until graphical.target has been hit" Mr Dog posted:<troll>yeah glib is a bloated mis-designed piece of crap, so what else is new</troll> Uh, well, your dbus-server and client need to poll on that connection, so that's two more syscalls in there. All of the eventfd's and close's were removed. The futexes / inter-thread IPC is a complicated thing which is required for the library to be thread-safe. libsystemd-bus doesn't have it.
|
|
#
?
Apr 28, 2015 20:30
|
|
|
Suspicious Dish posted:For reference, "early boot" means "from the beginnings of the initrd up until graphical.target has been hit" no, that's just "boot". once graphical.target has been hit you're not booting any more, you've booted.
|
|
#
?
Apr 28, 2015 20:53
|
|
|
Fair enough. We say "early boot" to mean "we want to do things from super early on up until boot finishes", which we do. It can't be available in late boot, it needs to be available as soon as DRM has initialized.
|
|
#
?
Apr 28, 2015 20:59
|
|
|
|
| # ? Jun 4, 2024 19:31 |
|
|
I was imaging weird network boot setups or full-disk decryption schemes, and it turns out it is for putting a sweet logo on the screen during boot.
|
|
#
?
Apr 28, 2015 21:13
|
|