|
how to make mouse wheel click work like windows?
|
#
?
Jan 29, 2015 04:51
|
|
|
|
| # ? May 27, 2024 09:30 |
|
|
it does already?
|
|
#
?
Jan 29, 2015 05:05
|
|
|
middle click 2 make the 4 way scroll thing? i doesnt on any flavor of ubutnu./..
|
|
#
?
Jan 29, 2015 05:06
|
|
|
oh. I use fedoras it does on mine.
|
|
#
?
Jan 29, 2015 05:08
|
|
|
Smythe posted:middle click 2 make the 4 way scroll thing? i doesnt on any flavor of ubutnu./.. istr kde apps default to this behavior Firefox and chrome require their own tweaks
|
|
#
?
Jan 29, 2015 05:11
|
|
|
my stepdads beer posted:oh. I use fedoras it does on mine. Notorious b.s.d. posted:istr kde apps default to this behavior thnx
|
|
#
?
Jan 29, 2015 05:12
|
|
|
http://article.gmane.org/gmane.linux.kernel.api/7762 watching the evolution of kdbus being discussed on lkml, it's a fun read not in the usual "lol look at these dysfunctional dumbasses" sense though, more the "drat these ppl are a lot better at what they do than i'll ever be" sense. lookin forward to seeing this land in mainline
|
|
#
?
Jan 29, 2015 17:21
|
|
|
Mr Dog posted:http://article.gmane.org/gmane.linux.kernel.api/7762 Yes it's a shame they're wasting their talent
|
|
#
?
Jan 29, 2015 18:51
|
|
|
KDE A big room somewhere in Europe with lots of chrome and glass and a great big whiteboard in the front with lots of tiny, neat writing on it. There are about 50 desks, each with headphones and pristine workstations, also with a lot of chrome and glass. The faint sound of classical music permeates the room, accompanying the clicky-click of 50 programmers typing or quietly talking in one of the appropriately assigned meeting areas. (Which of course consist of elegant contemporary white pine coffee tables surrounded by contemporary white pine and fine leather meeting chairs.) Coffee, tea, mineral water and fruit juices are available in the break area. At the end of the day, everyone checks in their code and the project leader does a "make" just to make sure it all compiles cleanly, but it's mostly only done from tradition anymore since it always compiles cleanly and works flawlessly. When all milestones have been met, and everything has been QA'd, (usually within a day or two of the roadmap that was written up 18 months previous) a new KDE release is packaged up and released to the mirror sites with the appropriate 24-hour delay for distribution before being announced. KDE developers are generally between the ages of 16 and 25, like art made of lines and squares and the colors white and black. When/if they finally stop taking government subsidies and get around to getting "real jobs," most of their salary will be taken in taxes so the socialist government can subsidize the care and feeding of the next generation of KDE developers, just like it did for them. A high percentage of KDE developers, during their mandatory 5 years of government military service, crack from their years of cultural dullness and flee Europe to become terrorists for the sheer joy to be found in killing random strangers for no discernible reason. GNOME An abandoned warehouse in San Francisco, kitted up as for a rave, electronica playing at 15db louder than "my ears are bleeding and I'm developing an aneurism" volumes and the windows all painted over black so that the strobe and spotlights and lasers can be seen better. Computers, mainly made of whatever stuff has been exchanged for crack or scavenged from dumpsters behind dot-bombs, are scattered around on whatever furniture is available, which also consists of whatever stuff has been exchanged for crack or scavenged from dumpsters behind dot-bombs. There's no break area, but you may be able to bum a beer (or more likely something harder) off of one of the developers hanging around, and they will probably be too jacked up on X, coke, acid, heroin, ether or all of the above to notice that you've taken anything. Development strategies are generally determined by whatever light show happens to be going on at the moment, when one of the developers will leap up and scream "I WANT IT TO LOOK JUST LIKE THAT" and then straight-arm his laptop against the wall in an hallucinogenic frenzy before vomiting copiously, passing out and falling face-down in the middle of the dance floor. There's no whiteboard, so developers diagram things out in the puddles of spilt beer, urine and vomit on the floor. At the end of the day - whenever that is since an equal number of programmers will be passed out at any given time - or really whenever someone happens to think of it (which is rarely), someone might type "make" on some machine somewhere, with mixed results. Generally nothing happens, so he/she shrugs his/her shoulders and wanders off to look for someone who might have more pink/black-striped pills. Once in a great while, generally in the unpleasant time between the come-down from the last thing they took and before whatever it was they took just now comes on fully, someone will tar up a bunch of random files and post it on a website someplace it as the next GNOME release, usually with a reference to some kind of monkey. GNOME developers rarely live past 25 and prefer "alternative" art - generally stuff made of feces that's "too edgy" for most people to "understand" or "like." Core GNOME developers are heavy Ketamine users. The bodies of GNOME developers can often be found in dumpsters or floating face-down in any sufficiently large body of water.
|
|
#
?
Jan 29, 2015 20:29
|
|
|
KDE 1 and KDE 2 were Good Desktop Environments while GNOME 1 was a poo poo pit if anything it's now the other way round. Though KDE 5 looks like at least parts of it were designed by somebody who has taken at least on graphics design class.
|
|
#
?
Jan 29, 2015 20:40
|
|
|
Mr Dog posted:KDE 1 and KDE 2 were Good Desktop Environments while GNOME 1 was a poo poo pit gnome never really sorted out its foundation libraries, even today. aside from the gui theme, what services can gnome provide an application? gconf?
|
|
#
?
Jan 29, 2015 20:44
|
|
|
Mr Dog posted:http://article.gmane.org/gmane.linux.kernel.api/7762 so what is kdbus actually for ? i don't understand the use case well enough to understand the mailing list thread
|
|
#
?
Jan 29, 2015 20:45
|
|
|
basically: make dbus faster. you'll probably rant about Solaris Doors now.
|
|
#
?
Jan 29, 2015 20:56
|
|
|
read the thread op, there's been a lot of back and forth about why kdbus is useful. my take on it: modern linux poo poo makes extensive use of many-to-many message passing communication via dbus, but everything has to go through a central router process which has to repeatedly copy and validate poo poo, so all those context switches and revalidations make it slower than it should be and it's a performance bottleneck at e.g. boot time. things like pulseaudio have to invent their own custom transport because dbus is too slow. also embedded ppl coming from qnx to linux (lol why) have a bunch of existing code that is designed to operate on top of a high-performance message passing system. lifecycle management for the central router process is also awkward because early userspace would like to be able to use it. udev iirc still abuses netlink for its ipc for this reason. systemd uses the dbus wire protocol but it has to do some gymnastics to perform ipc during early bootup before dbus-daemon is started up and available. despite what some people might believe nobody wants to merge dbus-daemon into systemd because the service manager has no business being a message broker as well. remember all this poo poo has to work from initramfs which often makes use of systemd itself to get enough poo poo loaded up that you can mount the root partition and launch the "real" systemd kdbus is a performant many-to-many message passing kernel primitive. you can launch your own buses and have them use whatever message format you want, but "the" system bus that all the cool system daemons hang out on uses a slightly improved version of the d-bus wire format to pass messages around. it also provides race-free metadata about sending processes and allows safe passing of shared memory buffers between mutually untrusting processes (although that's actually provided by memfd objects, which were broken out of kdbus and merged earlier as an independent ipc primitive, but kdbus is designed to pass poo poo around using memfds if it's large enough to be worth the extra overhead). there is no central message broker, you just need an initial process to create the bus and program in the policy that controls who can talk to who and how, so systemd can do this.
|
|
#
?
Jan 29, 2015 21:04
|
|
|
Mr Dog posted:also embedded ppl coming from qnx to linux (lol why)
|
|
#
?
Jan 29, 2015 21:07
|
|
|
matt garrett getting angry on twitter 'bout packaging
|
|
#
?
Jan 29, 2015 21:27
|
|
|
Mr Dog posted:kdbus is a performant many-to-many message passing kernel primitive. you can launch your own buses and have them use whatever message format you want, but "the" system bus that all the cool system daemons hang out on uses a slightly improved version of the d-bus wire format to pass messages around. it also provides race-free metadata about sending processes and allows safe passing of shared memory buffers between mutually untrusting processes (although that's actually provided by memfd objects, which were broken out of kdbus and merged earlier as an independent ipc primitive, but kdbus is designed to pass poo poo around using memfds if it's large enough to be worth the extra overhead). there is no central message broker, you just need an initial process to create the bus and program in the policy that controls who can talk to who and how, so systemd can do this. ok this sounds pretty cool a pity they had to brand it "dbus" because i associate dbus with bad things
|
|
#
?
Jan 29, 2015 21:31
|
|
|
I see gnome developers and other linux desktop people as being from north carolina, since that's where Red Hat is headquartered. Unless it's a big web services company (google, twitter, facebook), I don't really associate an open source workplace to actually be in the california bay area.
|
|
#
?
Jan 29, 2015 21:41
|
|
|
Notorious b.s.d. posted:ok this sounds pretty cool yeah, if it's supposed to be like dbus but fast and efficient and used by middle class people then they should have called it dtrain
|
|
#
?
Jan 29, 2015 23:00
|
|
|
Notorious b.s.d. posted:ok this sounds pretty cool iow they're reinventing Mach messages (poorly, I assume)
|
|
#
?
Jan 29, 2015 23:09
|
|
|
did Mach ports support broadcasts to multiple receivers?
|
|
#
?
Jan 29, 2015 23:18
|
|
|
Are Mach messages multicast? e:f,b
|
|
#
?
Jan 29, 2015 23:18
|
|
|
here's a question actually, why is it that Mach is poo poo and QNX isn't they're both kind of the same thing iirc
|
|
#
?
Jan 29, 2015 23:29
|
|
|
QNX is a realtime OS, Mach is nowhere near. QNX is also a lot like Binder, in that when sending a message from process A to process B, process A gives up its timeslice immediately to process B, without deferring to the thread scheduler. This means that messages are processed almost immediately. Mach simply waits for the scheduler to naturally context switch to the other thread.
|
|
#
?
Jan 30, 2015 00:08
|
|
|
Mr Dog posted:here's a question actually, why is it that Mach is poo poo and QNX isn't suspicious dish gave you an insightful but incomplete answer pertaining to microkernel architecture. the thing about mach is that nobody outside of academic research ever used it for microkernel anything. mach was envisioned as a bunch of "servers" (applications running in kernel) that provided services like drivers and network stacks and poo poo. unfortunately every real-world mach (osx, nextstep, compaq tru64, dec unix, intel osf/1, etc) just has one giant fuckin lovely "server" that implements all of UNIX as a service. this leaves you with all the overhead and bullshit that you get out of any microkernel, with none of the advantages the chimera setup crashes just as easily as a conventional unix but manages to be 100x slower on system calls
|
|
#
?
Jan 30, 2015 00:35
|
|
|
Wait, was that really it? Third-party microkernels running in ring 0? That is not a smart idea.
|
|
#
?
Jan 30, 2015 00:37
|
|
|
Suspicious Dish posted:Wait, was that really it? Third-party microkernels running in ring 0? That is not a smart idea. yeah the ring 0 is a key thing here. mach "servers" were originally intended to run in userspace. but this was like 10,000x slower than any normal kernel. the university of utah added In-Kernel Server (INKS) support to mach 3.0 . this reduced system call overhead from 10,000x to just like 100x, but meant that any given "server" could crash the system the idea was that you would develop and debug your servers in userspace, and then there would be 0 source code changes in order to make them work in INKS mode. you can guess how well this worked especially when almost all your system calls pass through one and only one server, and that single server is 9/10ths the size of a conventional unix kernel, including hardware drivers Notorious b.s.d. fucked around with this message at 00:43 on Jan 30, 2015 |
|
#
?
Jan 30, 2015 00:41
|
|
|
oh i forgot the best part the test case for source-compatible INKS support was the bsd-derived UNIX mega-server academics were passing around. they mention this offhand in the original INKS paper in other words the very first mach server to be running in ring 0 with almost no protections was the very thing that should absolutely not be there edit: i forgot how not-impressive the numbers are in the original INKS paper. obviously poo poo got faster. osx is not 10,000 times slower than linux anymore Notorious b.s.d. fucked around with this message at 00:47 on Jan 30, 2015 |
|
#
?
Jan 30, 2015 00:44
|
|
|
"Abstraction barriers for security purposes? THOSE JUST SLOW DOWN MY HIGH PERFORMANCE PLANG!"
|
|
#
?
Jan 30, 2015 01:15
|
|
|
Mr Dog posted:read the thread op, there's been a lot of back and forth about why kdbus is useful. my take on it: what you've described is basically Mach the many-to-many functionality is interesting, but in general this is textbook "why you want a microkernel" stuff, like literally what you will find in the OS textbooks that Linus didn't read edit: I will find some appropriate way to reward someone who posts to the list recommending the subsystem's official name be "Tanenbaum" because Andy was right
|
|
#
?
Jan 30, 2015 05:52
|
|
|
rip microkernels L4 showed that the overhead was mostly mach being really lovely about message passing. at some point i found a paper where l4/linux actually had a marginally faster systemcall somewhere even though it was running as a server over the l4 microkernel interestingly lots of qualcomm basebands run seL4, which is a verified C implementation derived from a haskell version of L4 L4 is p sweet too bad liedtke is dead rick rashid now runs OS research for microsoft other cool and dead projects: singularity (i assume), where they found that the overhead of paging and poo poo is extremely high compared to writing ur code in a language that is policed correctly
|
|
#
?
Jan 30, 2015 06:03
|
|
|
no Mach is "every system level activity should involve at least three context switches because reasons". Nobody's talking about putting the Linux TCP/IP stack or root filesystem drivers into user space. because that would be stupid. kdbus is a not-lovely ipc primitive that allows userspace processes to efficiently discover peers and pass messages to them. and also loosely couple with each other by means of pub/sub. dbus, on top of this kernel primitive, gives you a standardised and potentially reflectable event bus and automation framework for your system. no, exchanging program-specific artisanal byte-oriented ascii stream formats that purport to be both user-friendly and machine-friendly while being poo poo at both of those things is not a better way of doing things than having a fast and standardised machine-friendly mechanism for tying poo poo together.
|
|
#
?
Jan 30, 2015 06:06
|
|
|
pseudorandom name posted:did Mach ports support broadcasts to multiple receivers? Suspicious Dish posted:Are Mach messages multicast? idk i was shitposting tbh
|
|
#
?
Jan 30, 2015 06:08
|
|
|
Malcolm XML posted:other cool and dead projects: singularity (i assume), where they found that the overhead of paging and poo poo is extremely high compared to writing ur code in a language that is policed correctly tanenbaum did touch on this in one of his books, the fact that operating systems are responsible for doing two things: 1. securely sharing resources between processes 2. providing a friendly abstraction over bare hardware os design in the past few decades has shown that objective #2 is a really lovely idea because no one abstraction fits all applications (consider how db servers all actively fight the operating system's vm subsystem, filesystem, and io caching layer, with the honorable exception of Redis) and whatever one is foisted upon you by the OS is the one you're stuck with. Exokernels are an interesting idea because they explore the structure of a system that makes absolutely no effort to do anything other than make each user's programs play nice with each other. though they are a bit fundamentalist about it (the way they allow unprivileged filesystems to securely share the disk using only their own metadata through some side-effect-free functions provided to a kernel-based interpreter that can statically verify certain properties that ensure they do in fact play nice is pretty cool. the linux ppl are slowly rediscovering this research via the evolution of the BPF interpreter). anyway yeah singularity forces the entire computer to use the .NET type system so you're effectively forced to use C# or C# wearing your choice of syntactic lipstick. not a winning strategy in practice i don't think.
|
|
#
?
Jan 30, 2015 06:12
|
|
|
Mr Dog posted:Nobody's talking about putting the Linux TCP/IP stack or root filesystem drivers into user space. because that would be stupid. Actually, people are talking about the former and actively doing the later (lol ntfs-3g) right now.
|
|
#
?
Jan 30, 2015 06:12
|
|
|
Notorious b.s.d. posted:unfortunately every real-world mach (osx, nextstep, compaq tru64, dec unix, intel osf/1, etc) just has one giant fuckin lovely "server" that implements all of UNIX as a service. this leaves you with all the overhead and bullshit that you get out of any microkernel, with none of the advantages i have seen this said over and over and i'm always curious about what exactly this mysterious overhead and bullshit is when you aren't paying it because it isn't there because the unix server lives inside ring 0 and different parts of the unix server do not in fact have to communicate through ipc primitives because everything's a function call away that's my impression (could be wrong i am not a real expert) of how the darwin kernel actually works. it's a funy monolithic bsd with some layers replaced by mach code (vm, scheduler), and the drivers ripped out and replaced by iokit. and of course mach ipc is still provided as a service to userspace. the osx performance issues everyone gets excited about? as i understand it, much of it is that mach vm is rather heavyweight compared to linux vm, thanks to architectural choices which cant be wholly optimized away. iow, something which is orthogonal to the holy war over whether to structure an operation system as a fleet of mini servers in separate address spaces. i've been told before that the upper layers of osx (in particular the window server) get a lot out of mach vm's unique features so the overhead might actually be worth it
|
|
#
?
Jan 30, 2015 06:39
|
|
|
pseudorandom name posted:Actually, people are talking about the former and actively doing the later (lol ntfs-3g) right now. Finally, the day for SLIRP to shine.
|
|
#
?
Jan 30, 2015 06:43
|
|
|
this thread is extremely triggering
|
|
#
?
Jan 30, 2015 06:49
|
|
|
is it triggering you to install linux on your desktop?
|
|
#
?
Jan 30, 2015 07:01
|
|
|
|
| # ? May 27, 2024 09:30 |
|
|
quite not
|
|
#
?
Jan 30, 2015 07:12
|
|