Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 10:11 AM, Bastien Nocera wrote: The defaults for the various products are "packaged" by zones. You just need to change the firewalld zone to get whatever is the default on the server side. Ok, so it's another item on my list of "things to fix that fedora didn't get right" after I do an install. The release notes are misleading, at best. All of the arguments I've heard used to justify this change have been boiled down to "end users don't understand networking" -- which means that calling this feature "developer oriented" in the release notes is wrong. There should be a far larger warning that any software that opens a non-privileged port is accessible to the world. If I didn't do development (and if I hadn't read this thread) then I would probably have skipped that section and left my machine open to the world. Or better, use VMs to deploy test instances which would have the same set of packages and configuration as a Fedora Server version. Proposing VMs is just moving the goalposts, especially if I have client-oriented software that wants to open ports. And for developer things it means maintaining/securing two installations instead of one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 11:46 AM, Richard Hughes wrote: I don't think it makes much sense for people to stamp their feet saying "BUT I LIKED THE OLD WAY OF DOING THINGS" when the people leading the workstation product have identified that the old way of doing things just doesn't work for the majority of people. You're probably not in that majority, but that doesn't mean the change is in someway intrinsically flawed. Nor does it mean that the change is intrinsically right! Every pro argument on the list about this has been because "firewalls are hard" for most users. At the same time the release notes are saying that the change is for developers (2.3.3) -- and devoting half of the opening sentence to the media sharing use case. If someone is a developer then they should have a hurdle before opening their potentially dangerous code to the outside world. The media sharing use case is really the crux here, and I appreciate the issues involved. However, instead of turning off the firewall to non-privileged ports, why not create a tool that opens the involved ports that's driven by the user? That seems a much better solution than disabling the firewall to make media sharing easier. If it isn't ready, it should have been pushed to F22. The biggest problem I have with it is that it's a huge security policy change that has a relatively tiny note in the release notes. I know multiple people in my department (developers) will end up with databases, tomcats, rails, and other network-based servers on the open net because they didn't see the notice in the release notes. Personally, I'll just add it to the "poor choices that fedora made that I'll undo at install time" list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 01:45 PM, Bastien Nocera wrote: - Original Message - Richard Hughes wrote: So do I! I'm a developer, which spin do I use so that the firewall doesn't get in my way? We can't develop a *product* based around what you specifically want, not me, nor anyone else on this list. If you're a developer, surely you know what a port is and can make a few clicks in firewall-config or system-config-firewall to open it! A "developer" who can't even figure that out is a HORRIBLE developer! Still waiting for that answer about the rygel use case. You'll see how much of a HORRIBLE setup this can be... How, exactly, is a home media solution a key requirement for the "Developer oriented" firewall touted by the release notes? This is the problem I've got with this feature. It has nothing to do with developers and everything to do with making a gnome feature work without having to click a "I really want to open everything because I'm on a trusted network" box. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
Out of curiosity, is the cirrus driver used in qemu/kvm or does it use something else? On 08/27/2013 10:46 AM, Adam Jackson wrote: For F21, I plan to orphan the following X video drivers: xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident Effectively this means that the graphics team will be focusing on KMS for graphics support, with vesa and fbdev available as last-ditch fallbacks. If anyone is interested in taking on support for these chips, they're welcome to, though we would encourage anyone doing so to work towards KMS support and not merely do keep it building maintenance. One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa. Again, if someone wants to own the i810 support, let me know and we can add you as a comaintainer. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the Fedora boot experience
Repeating that fast boot times matter is just as bogus as saying they don't. The 2 or 3 seconds that's being talked about here has no meaningful impact on anything other than embedded users and they're probably not using grub anyway. Fedora 18 screwed my laptop pretty thoroughly since the ATI drivers would hang the machine on resume. Having the menu there so I could chose an alternate kernel was a godsend, especially since the newer kernel wasn't always better than the previous. 2 seconds isn't hurting anyone and its more than likely going to make it easier on someone to have that menu there. Many non-server systems hibernate or suspend anyway, so they're only going to see the menu on a hard reboot. Additionally, having the ability to hit escape and see what is going on when the progress bar has hung has also saved me on occasion. On 03/12/2013 09:33 AM, Lennart Poettering wrote: On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. This is way up on my list of most non-sensical arguments about building OSes, right next to Linux is about choice. This bullshit about boot times don't matter is just entirely bogus, and it doesn't get better by constant repitition. Fast boot times matter on desktops, they matter on embedded, they matter on mobile, they matter or servers, they matter everywhere. Fast boot times matter to dual-boot users, they matter to everybdoy who doesn't run his system 24/7, they matter in container setups, they matter in HA setups, they matter in the cloud, they matter for people who update their system, they matter to people with discontiniuous power supplies, they matter to provide users with a sane user experience. Fast boot times save you time and energy. They increase reliability, and applicability. Fast boot times improve the first impression our OS makes on people. And yes, I know that some BIOSes suck, and are slower than the OS to boot. But that's -- for once -- something that *does* not matter, and is no excuse for having everything else to be slow, too. The Windows 8 certification *requires* fast POST from all machines, and so, it's only getting better, and we should do our bit about it. You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. Lennart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 02:03 PM, Chris Murphy wrote: On Mar 12, 2013, at 10:35 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 17:32, schrieb Chris Murphy: On Mar 12, 2013, at 6:02 AM, Jiří Eischmann eischm...@redhat.com wrote: New kernels bring a lot of regressions and we don't have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve. This is completely specious. A user who considers falling back to an older kernel as a troubleshooting step also knows how this selection is made and where to go look for it THIS IS WRONG Oh really? Yes, it is wrong. We're not talking about just new users here. If you're going to hide how to select a different kernel, how am I, an experienced sysadmin supposed to figure it out when things go south? F18 screwed my computer royally with regards to sleep restore and I had to boot older kernels to get the machine stable. As it stands, there were a list of kernels I chose the upper most one which didn't have problems...under what people are proposing I'd have to google it on some other machine or just mash the keyboard and hope I find something that gives me some options I don't know why people are so enamored by making it difficult to troubleshoot problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Fedora isn't windows. Its not OSX. It should never be those things and I'm grateful for it. The boot menu doesn't hurt anything. It has benefits. What are the benefits of removing the boot menu? * Saving upwards of 5 seconds per day! My god, think of the productivity boost! * Its prettier. Wow. Neat. Huh. Why is this even being considered? On 03/12/2013 02:17 PM, Chris Murphy wrote: On Mar 12, 2013, at 12:01 PM, Alec Leamas leamas.a...@gmail.com wrote: I *do* appreciate the attempts to get a clean, graphically consistent boot experience. And to be frank, I wonder if not WIn 8 (and perhaps Mac) has got it right. It's just that a Fedora box isn't a Win8 or a Mac, and the boot UI cant change that. Windows and OS X get away with a simpler experience, both user and MS/Apple development side, because of hardware certification (control). And they don't expect to interoperate that well with other OSs. A more capable heuristic is needed as Fedora boots, to account for events those systems don't need to. So if Windows and OS X have the ux right, Fedora can do it even better by getting more things right under the hood. That benefits everyone, not just new users. It benefits remote VM or metal rebooting after a kernel update causes a problem, and 'self heals' by automatically falling back to a prior kernel in case that'll help resolve the problem. With btrfs snapshots before updates, more than just the prior kernel can be fallen back to. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 02:35 PM, Tomasz Torcz wrote: On Tue, Mar 12, 2013 at 02:31:36PM -0400, Brian Wheeler wrote: Fedora isn't windows. Its not OSX. It should never be those things and I'm grateful for it. We shouldn't ignore developments done in other camps. NIH is bad. Of course it is. What are the benefits of removing the boot menu? * Saving upwards of 5 seconds per day! My god, think of the productivity boost! * Its prettier. Wow. Neat. Huh. Why is this even being considered? Some of us really appreciate aesthetic. At the cost of functionality and/or maintainability? No thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 07/13/2012 10:14 AM, Dennis Jacobfeuerborn wrote: On 07/13/2012 09:14 AM, Roberto Ragusa wrote: On 07/12/2012 09:54 PM, Harald Hoyer wrote: Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time. As I have already pointed out some time ago, isn't a bizarre situation that as an application developer I can either use malloc() and store things up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store things up to RAM/2 (lets' say 4/2=2GB)? Once upon a time you used to use files to go *beyond* RAM limits. And the answer to this objection is? move to /var/tmp. So patch everything (and good luck with closed source stuff). An application (closed source or not) that plans to store non-trivial amounts of data somewhere should have a mechanism/config option to let the user specify where to store that data. Simply hoping that you can dump X gigabytes of data in some hard-coded place is not a good idea. Sure, its not a good idea, but its been done for decades...successfully. Wouldn't have been more reasonable to create a /ramtmp and patch the applications? (this would have just been patched for speed, not patched for correctness as the sort case). Hey, wait, we already have /dev/shm. So we just had to patch the applications (if anyone cares). That way *every* application would have to be patched. Using /var/tmp is only required for a small number of apps that actually have more specific needs regarding the data they intend to put there. And right here is the problem. The more specific need is now based on size of the data relative to the amount of memory in the machine. That's just messed up. Does anaconda on F18 put /home and / on different volumes? I did a rawhide install using the F17 and all defaults and they're combined. Under this scenario I have sizeof(rootfs) - 5G of disk I can potentially use for /tmp. Under the tmpfs scheme I have 1G (this is a 2G VM) . The answer is, of course, to use /var/tmp -- which only moved the problem and didn't do squat except to generate a bunch of patches which amounted to s|/tmp|/var/tmp|g To make this a default was a dumb decision which has never been adequately justified. I did finally see some performance numbers for a software build, but that isn't the general case and I can't believe the benefits touted even impact the general case, especially given the size limitations of /tmp. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
So, how does this scenario work? * The machine has 4G of RAM, * 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other 50% is pagecache * The machine has 4G of swap, none of which is active. So then a user drops a 8.5G DVD image into /tmp. On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root. With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? As I understand it, the program gets ENOSPC and there is NO free RAM: pagecache is full of that dvd data. swap is full of that dvd data. The rest of the RAM is program data that has nowhere to page out to. The system may not have crashed, but it is fubar: welcome to OOM killer territory The answers of don't do that, use /var/tmp or allocate more swap are crap. The software isn't broken if it writes to /tmp, regardless of how many bugzilla entries get filed. Allocating more swap is a cop out because you've only pushed the problem to some file size that is larger, and you've tied up disk for a worst case scenario that may never come. This introduces behavior that is highly dependent not only on the memory configuration of the machine, but the usage at the time the allocation happened, making this impossible to troubleshoot. What are the benefits of this change again? Clearing /tmp at shutdown is interesting, but can be accomplished in other ways (although not as cleanly), and I have yet to see any hard numbers on I/O even though I have asked repeatedly. Brian On 06/20/2012 01:18 PM, Gregory Maxwell wrote: On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.rei...@thelounge.net wrote: i bet now someone is coming up wth he must not dump a 100 Gb file to /tmp this is the wrong perspective the right one is the system must not crash if someone does Good thing it doesn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 01:41 PM, Gregory Maxwell wrote: What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the Open in facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown? Yes, Firefox saves to /tmp by default. Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems. I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation. With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure. Its not just writing out the data that needs to be measured, but any case where the threshold of memory-used-for-software crosses the tmpfs limit: loading libreoffice when the machine has more than 50% ram used by software is going to generate a bunch of writes as well as a ton of reads at the same time, rather than having them spaced out over time (potentially, at least) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 01:55 PM, Chris Adams wrote: Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: So, how does this scenario work? * The machine has 4G of RAM, * 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other 50% is pagecache * The machine has 4G of swap, none of which is active. So then a user drops a 8.5G DVD image into /tmp. On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root. With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? 2G gets written and then -ENOSPC. 2G gets pushed to swap. The default for tmpfs mounts is an fs that is sized to RAM/2. So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/20/2012 02:16 PM, Gregory Maxwell wrote: On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta jspal...@gmail.com wrote: On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default. Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up? It's 50% available at bootup by default (e.g. this is what you get when you provide no size option while mounting). I'm not sure what the systemd stuff is doing, I had the impression it was leaving this as a default. I don't know if this is a good thing or not. On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler bdwhe...@indiana.edu wrote: I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation. With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure. An anticdote is not data, but I've never personally experienced negative thrashing behavior from high tmpfs usage. I suppose thrashing only really happens when there is latency sensitive competition for the IO, and the kernel must be aggressive enough to avoid that. I was pretty sure that on the internet an anecdote == data. :) When data is written to file systems normally the bulk will also remain in the buffer cache for a some span of time until there is memory pressure. The difference is how long it can remain (tmpfs has no mandatory flush) before being backed by disk, how much extra overhead there is from maintaining metadata (less for tmpfs than persistent file systems), and how much must be written right away to keep the fs consistent (none for tmpfs). Perhaps, but if you've dumped a big file to /tmp on a real filesystem and then a minute or two later you startup something large, its probable that the kernel has flushed the data to disk and the pagecache has easily discardable pages to use for new data coming in. Under tmpfs the flush would be forced on page discard which would also be when things were being read into the system. But in any case the I/O advantages have never been shown, despite multiple requests by myself and others. On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler bdwhe...@indiana.edu wrote: So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram? On systems where tmpfs is provisioned for /tmp in fstab you change a setting to get more space (provide size=fooG mount option). This is easier than adding more space to tmp when tmp is on root or some other file system. Well, yes and no. You also have to make sure you have enough backing swap or you're screwing yourself out of usable ram. The problem here is that the amount of /tmp by default is small by default so the tinkering with sizes is actually more likely to be required that it was before. And moving the requirement for large files (for some value of 'large' which depends on your memory configuration) to /var/tmp is just moving goalposts and not actually solving anything. I don't know how it will be set in systemd. Regardless of what systemd offers you could still toss in an option to remount it with more space after bootup. Buying more ram to increase /tmp is silly of course. The default behavior is just a default it doesn't imply some kind of cosmic relationship between your tmpfs size and the amount of physical ram. Ah, but it is the default. Because of this, there are going to be dumbass howto sites out there saying that Fedora is broken because it requires you to buy more RAM to get increased swap space -- no matter how many times it is refuted here. So I built a rawhide vm just now with 2G of ram and while it didn't move /tmp to tmpfs (maybe because it was an upgrade?), /run is in tmpfs and I did some experiments. Yes, it did limit me to 1G when writing a file which is fine -- except that as a user that is substantially smaller than the (disk size - 6G) size that one would have had on /tmp if it was on /. Which means that many users are going to have to mess with that setting in order to preserve their current workflow and/or solve
Re: Intent to retire: nss_ldap
on our RHEL6 servers I'm still using nss_ldap for the hosts database: we have a private network and I don't want to copy portions of /etc/hosts around to our servers and putting them into DNS isn't really an option for us. I couldn't find an easy way to look up the data in ldap for that data so I just stuck with nss_ldap for all of the databases we needed. Brian On 06/07/2012 05:20 PM, Jakub Hrozek wrote: Hi, I would like to retire PADL's nss_ldap and pam_ldap from current Rawhide. SSSD has been the default in Fedora for quite a few releases with nss-pam-ldapd as another option for deployments that, for some reason, do not want to migrate to the SSSD. nss_ldap also seems to be abandoned upstream. Are there still any users of nss_ldap? If so, what are the reasons keeping you from using either nss-pam-ldapd or the SSSD? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to retire: nss_ldap
I'll investigate it when we get to another system change but since its working on the current servers I'm not touching it :) By the time we do an OS refresh I'll probably try moving to IPA Brian On 06/08/2012 10:14 AM, Stephen Gallagher wrote: On Fri, 2012-06-08 at 09:06 -0400, Brian Wheeler wrote: on our RHEL6 servers I'm still using nss_ldap for the hosts database: we have a private network and I don't want to copy portions of /etc/hosts around to our servers and putting them into DNS isn't really an option for us. I couldn't find an easy way to look up the data in ldap for that data so I just stuck with nss_ldap for all of the databases we needed. Sure, but you should be able to use nss-pam-ldapd for that now. Have you given that a look? (It's essentially the direct replacement for nss_ldap and pam_ldapd supported by PADL). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 08:12 AM, Alexey I. Froloff wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? So if things start acting up the answer is to add more swap and mess with fstab? WTF? So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Sorry guys, this feature sucks. The rationale was and is handwavy at best and none of the legitimate concerns which have been raised have been answered in any meaningful fashion. There have never been any numbers showing the IO/power benefit claims are true. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 10:23 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) So that means that random users care about YOU! In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). Sure. When there's mystery problems , who is going to think oh yeah, /tmp is in ram now and chrome just wrote a big temp file...better go look up how to add swap? I'm going to guess 'nearly nobody' So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... The thing is, the amount of reasonable swap is now not a function of just RAM overflow but also /tmp usage -- which is something that can vary dramatically at runtime. So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sure, no software _should_ use it directly, but it happens a lot...and not in packages which are in the repo: home grown and third party. Additionally, there's 20+ years of habit to break for a lot of people and that's not something you can easily patch. Running things like grep \\ 404\ apache.log /tmp/404s.log is pretty ingrained for many people. I'll probably turn it off because I've been down this road with Solaris and it sucked. I will grant that the linux implementation is better, but I want RAM to be used for the running software and if its not being used for that, caching what's actively being used. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:35 AM, Gregory Maxwell wrote: Because that disk activity only happens when the kernel decides that it wants the memory for something else it doesn't happen at all in a great many cases especially for short lived files. ... The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed. Um, aren't both of those benefits the same as one would get when using ext4's delayed allocation? Does anyone have any actual numbers for the performance increase? I've never seen any numbers, but I've heard the claim repeatedly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:52 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. Wouldn't the things which modify important stuff in / be running as root? If so, they'd get that 5% to play with. In any case, I see your point. However, I can't say that it has happened to me since the days of 32M roots :) And tmpfs is faster than any other filesystem, and easily resized both ways. Not really, though. You have to muck with adding and removing swap partitions if you have workload that is biggish. I keep a 2G swap on all of my systems so /tmp as tmpfs is going to do poorly on them and since the disk is pretty much allocated elsewhere I can't just move files around to get more /tmp (or / if things are going wonky). How would an upgrade deal with that situation? Its very much like the traditional commercial unixes which would have a separate filesystem for everything: free space was never in the place where you actually needed it. I'll grant that tmpfs is faster than other filesystems, but is it a win on a real workload? I haven't seen anyone answer that. It seems like this feature is trading a set of well-known problems for a different set of problems without a killer reason. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 12:21 PM, Lennart Poettering wrote: I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future... Lennart I understand how memory management works...which is why this seems like a terrible idea. Can you provide numbers that show that there is a speed increase with this scheme which offsets the amount of change required to do this? I haven't seen anything other than its faster. This is change is troublesome for multiple reasons: * It switches the semantics of what /tmp is. Its now apparently for small and short-lived files. Where small and short-lived are defined based on the RAM usage at the time a file is created. Hooray for heisenbugs! * everything that did use /tmp now should use /var/tmp which means patching a ton of programs and hoping that third party applications do the same thing. So the problem this fixes with /tmp now exists in /var/tmp. * there are no numbers which back up the purported benefits * file data gets moved out of RAM (in this case, to swap) not when it is convenient for the kernel at a potentially idle time but when the kernel is experiencing memory pressure. * changing the amount of space available in /tmp means screwing with swap files How is this change a win? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 05/31/2012 08:59 AM, Lennart Poettering wrote: On Thu, 31.05.12 08:51, Matthew Miller (mat...@mattdm.org) wrote: On Thu, May 31, 2012 at 12:55:28PM +0200, Ralf Corsepius wrote: Now /var/tmp should be more persistent which we don't need, Correct, using /var/tmp is wrong and a mistake. IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS. Well, not just FHS, but traditional usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day. Does that matter? We still have 10d and 30d clean-up for that. With one addition though: /tmp is also flushed on reboot. Lennart I'm still unsure what the point of this feature really is. The wiki page lists the features as: * By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster. Do we have actual numbers for this? It would seem like we already have this with ext4's deferred allocation and the pagecache. * /tmp is automatically flushed at boot. It seems like adding an rm to the startup sequence would do this with less surprises. * We bring Fedora closer to commercial Unixes and other Linux distributions. Um, so? Any solaris admin worth their salt kills the ram-based /tmp as soon as the install is finished. Its been that way since the 90's. * We make the delta to stateless read-only systems smaller. Why is this a win for the normal user? The page says the user experience should barely change -- which I think is really downplaying the scope of this change. Firstly, the cleanup of /tmp on reboot is a behavior change that is going to bite a lot of people, no matter how bold and large it appears in the release notes. This isn't terribly controversial, but it still sucks for those who get hit by it. More importantly, the restriction that /tmp be used for files that are less than an installation-defined size is going to cause a lot of problems. Patching everything to use /var/tmp because we don't know how big the data file is going to be in advance just moves the problem somewhere else and doesn't solve anything. There are going to be mystery disk full messages and issues on low memory machines. So why are we doing this again? How is this a benefit to the normal user? At the most, this should be an opt-in feature rather than the default. Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/06/2012 02:50 PM, Chris Murphy wrote: What happens to /tmp on tmpfs when real memory and swap are completely consumed? I assume it would get an -ENOSPC...but with RAM and swap being full I don't expect that the end user would ever see the error before the machine bogged down to the point of being unusable. Of course, I could be wrong. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/03/2012 10:31 AM, Chris Murphy wrote: /tmp is a like a litter box. From a user perspective, I'm happy to have it emptied regularly, because clearly the cats don't clean up their own doodles. That one of the cats might think he's deposited something valuable that he'll come back for someday, is hilarious to me, as well as ridiculous. My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. Indeed. I don't mind the cleaning of /tmp on reboots although I'm going to have to warn my users. I've got two concerns about this change: * The (user|program) has to decide the location for temporary data based on its size. There have been arguments that everyone should have been using /var/tmp for ages but I'm not buying it. I suppose that made sense when there were separate /var and / partitions, but that hasn't been the case _ever_ for me on Linux and its been a long time since I did that on other platforms. * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. Maybe I'm overreacting, but I've not seen a convincing case on why this has to be made the default rather than an opt-in situation. I certainly can't see this being a configuration I'd choose for my servers or any machine which may be memory limited. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/02/2012 07:44 PM, Dave Jones wrote: On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster. What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs? tmpfs contents are pageable, and will be swapped out if necessary. I can't say that as a user (and sysadmin) I'm really thrilled with this. /tmp doesn't go away on reboots now so this is a biggish change from my point of view. There have been several times where I've dumped things in /tmp that I needed after a reboot. I really don't care what the LSB recommends in this case: this is a pretty big behavior change. The hand-wavy rule for big files going to /var/tmp and little things going to /tmp is also gross since its creating a distinction that really doesn't need to be there. I've also dealt with sloppy users in the past that would write things to a tmpfs /tmp (on solaris) and not clean them up. Yes, its a programming issue, but I can't always control my users so instead of giving warnings that the disk was getting full the performance went to hell because it was swapping like crazy. I've looked at the benefits page on the wiki and I'm not seeing any benefits to me. It seems more like someone that needed this solution would want to opt in to rather than forcing others to opt out of it. Is there a reason why a symlink from /tmp - /var/tmp and leaving /var/tmp on a real disk isn't sufficient for whatever is trying to be solved here? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Fri, 2011-06-17 at 13:05 -0400, Bernd Stramm wrote: It all looks very pretty though. Maybe someone can answer this... All of the fade and animation effects that a lot of the toolkits/desktops are using these days seem like they're making the responsiveness substantially worse. I'm not referring to machine performance so much as the amount of time it (seems) to take to be able to interact with something. So, my question is: are the effects increasing the time between requested action and the ability to interact, or are they covering up the dead time that would have been there anyway, a la startup screens? From my vantage point, I'd much rather have things just snap on/off instead of watching them be all analog-y :) Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On Mon, 2011-06-13 at 20:36 +0200, Reindl Harald wrote: first sorry for some bad words from mine, but this is how i feel in a situation not knowing how to act since upgraded short ago to F14 in the hope get my energy refreshed staying there for some months and now realizing i will newer get new intel hardware well supportd on it __ please respect that some people are having really troubles with their health (what is happening to me this time in a way i wish not for my worst enemy), trying to make a great job at the same time as far as it is possible many of them (as i) have taken responsible for a lot of systems running really well with F14 and are having simply not the mental and physical energy to switch their whole setup in an invasive way but they are forced to do this because they needed new hardware and if you buy hardware now which should work 5 years or longer you will take the latest generation :-( __ As others have said: you chose the wrong tool for the job. Fedora isn't for running on anything you want to keep stable in service for a long time. Heck, even the http://fedoraproject.org/en/about-fedora page explicitly says that fedora devs don't mind shaking up the status quo, when it means we can more effectively move free software forward So maybe you should consider switching your servers to a RHEL 6 (or clone) so they'll be stable and have new hardware support. Heck, even for my home servers I don't run fedora because shaking it up every 6 months or so is a pain...I can't imagine trying it on production servers. Brian [For the record, I like systemd, but I couldn't stomach Gnome3. So the F15 upgrade was a mixed bag for me. Switched to XFCE and I'm happy again] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:19 -0500, Chris Adams wrote: Once upon a time, Jeff Garzik jgar...@pobox.com said: Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed. How many data centers run X on servers? I know I don't; they all boot runlevel 3 and just have a serial console (KVM switches are for Windows machines). I run in runlevel 3 so its not turned on, but I do have X installed and I'll start it in the datacenter (on a non-broken machine!) when I'm looking up docs, remoting my workstation to browse my email, etc. So it might not be running daily, but its there. Brian -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 19:12 +0100, Dennis Jacobfeuerborn wrote: On 11/09/2010 06:12 PM, Gregory Maxwell wrote: On Tue, Nov 9, 2010 at 11:55 AM, Adam Jacksona...@redhat.com wrote: On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing. I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends. And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Answering that you can still use X on top of Wayland doesn't do anything: it is the native Wayland clients that are the issue. If they are not network transparent then it cannot be a suitable replacement for X because native clients _will_ appear and we end up with the situation of OSX and Windows where some clients are more equal than others. [snip] Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm rather confused. Can you help me understand? So long as integrated network transparency doesn't get any worse I don't think that anyone raising concerns would have an issue. X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. Are the native wayland clients network transparent? If they are not, then it isn't a suitable replacement for X for my usage (or my 2 dozen users) and it means that either the native wayland clients or X clients will be second class citizens as time goes on. That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this. Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. Which should be considered now. VNC screen scraping sucks. If the native clients cannot be networked from the beginning, then they will never be able to be networked in a suitable fashon. Its not something you can bolt on later if [it] is really successful I like the concept of the project and I like the energy, but the bottom line is: if you want to make a replacement for X it needs to offer at least the same feature set. That includes network transparency. Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote: On Tue, 2010-11-09 at 12:12 -0500, Gregory Maxwell wrote: Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. One message ago you were saying that the network transparency concern was a non-issue because GTK/QT apps would support both wayland and X. Here you're saying that wayland will have network transparency? I'm Adam Jackson. That was Adam Williamson. We look a bit alike over ASCII I suppose, but in meatspace my hair is more likely to be interesting colors. And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work. So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always kept in sync. The truth is, I think this could be an interesting project, and I think most people are raising their concerns now to make sure that should it become a successful project we're not stuck with either VNC or local-only. Brian - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:19 -0500, Adam Jackson wrote: On Tue, 2010-11-09 at 14:01 -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 13:47 -0500, Adam Jackson wrote: And I'm saying you can get the network remoting effect you like in X, in Wayland. It's not built into the local Wayland rendering system, but there are both trivial ways to add it (vnc-like) and complicated ways to add it (rdp-like) and both will work. So would it be a rooted VNC? If so, that simply sucks. The rdp style is better, but I have a sneaking suspicion that it is going to be hit or miss in different toolkits the same way that GUI/TUI admin tools are always kept in sync. Sorry, I assumed a bit much domain knowledge here. No worries When I say vnc-like I mean let's scrape the pixels out of the rendering buffer and shove them over the wire. VNC itself is rooted, but vnc-like remoting can be rooted or rootless. In wayland the fundamental object of composition is a whole window, so you have scrapeable surfaces both at the window level and at the top level. Take your pick. I was hoping that window-level scraping was possible but I wasn't sure how to phrase it. When I say rdp-like I mean instill enough awareness of the possibility of remoting in the rendering system that remoting can send a rendering command stream instead of raw pixels if that seems to be a win. Wordy, I admit. And, obviously, much more work than just vnc-like scraping. But it's a serious win for WAN links, and is the only viable way to remote 3D, etc. Wordy, true, but I think its the kind of detail necessary to calm a lot of the fears that people have. And, of course, you can have both at once. rdp-like remoting probably requires toolkit awareness (in this bizarro world, the nested X server counts as a toolkit!), so if you end up remoting an app that lacks that level of toolkit support, you can fall back to vnc-like. Sounds reasonable enough Brian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor. Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both. I assume there would be a fallback method for older ssh clients? In any case, combined with the stuff that ajax has said in the last couple of emails it sounds like it could be a workable solution. Brian --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, 2010-04-20 at 10:00 +0300, Slava Zanko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Murphy wrote: Bookmark this: http://ss64.com/bash/ I know about :) This idea just try for standartization of command names... I know about posix and LSB, but these standards don't make logic in the names of commands. Okay, as I see, this idea don't have interest for most... To All: in any case, thanks for attention. Honestly it doesn't effect me since my brain has long since been molded into the unix way, but what about this as an alternative idea: In addition to dumping out options when --help is specified, perhaps an option like --helpxml could be added (maybe even generated from the gnu getopts data) to dump out information about how the program is used as well as the options. Then a gui tool or other front end could parse that XML and generate an interface for the end users. AIX (I think) used to have that for some of the more esoteric sysadmin tools, but they were one-off wrappers. It might make it easier for some people to build complex command lines that use lots of piping...say for parsing logs or something: gunzip -fc /www/logs/access* | grep GET /status | cut -f 1 -d\ | sort | uniq -c | sort -n Or, even as a worst case, perhaps man pages could be parsed, but that is probably a road to madness. Brian - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLzVDzb3oGR6aVLpoRAuIcAJ4qqkjvdiJrI/HugEK9igYKMrdFFACePVrB XpjNndoiHl0fgk44C/SGIK8= =tyjV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
