Re: [arch-general] KMS and external monitor resolution
On Wed, Jan 13, 2010 at 01:50:02AM +0100, Damjan Georgievski wrote: > > I'm sorry if it has already been discussed here, but I couldn't find > > anything with the keywords I was using. I even had a bad time choosing > > this message subject. > > xrandr ? > > > I bought a new, bigger monitor to use with my notebook. I've already > > configured X, but sometimes I like to write on the tty (there are less > > distractions there) and I'm having a little problem with it. > > > > The native resolution of the notebook screen is 1280x800 and the native > > resolution of the external monitor is 1920x1080, so when I'm on the tty, > > the external monitor uses only a box on the top left side with a size of > > 1280x800. > > > > What I would like to do is turn off the notebook monitor and use only the > > external monitor with its native resolution, without, of course, messing > > with my X setup, as it's already set. > > > > I'm using a Intel GMA965 with KMS. > > it should support virtual size of 4096x4096 by default, so you are fine. > > > > -- > damjan As I said, X is fine. My problem is when using the ttys (alt-f[1-6]), and xrandr doesn't work there. -- Andre
[arch-general] KMS and external monitor resolution
Hi all, I'm sorry if it has already been discussed here, but I couldn't find anything with the keywords I was using. I even had a bad time choosing this message subject. I bought a new, bigger monitor to use with my notebook. I've already configured X, but sometimes I like to write on the tty (there are less distractions there) and I'm having a little problem with it. The native resolution of the notebook screen is 1280x800 and the native resolution of the external monitor is 1920x1080, so when I'm on the tty, the external monitor uses only a box on the top left side with a size of 1280x800. What I would like to do is turn off the notebook monitor and use only the external monitor with its native resolution, without, of course, messing with my X setup, as it's already set. I'm using a Intel GMA965 with KMS. TIA Bye, Andre
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 03, 2009 at 05:05:18PM -0200, Denis A. Altoé Falqueto wrote: > On Thu, Dec 3, 2009 at 4:53 PM, André Ramaciotti da Silva > wrote: > > I believe these aren't the 'other IPC mechanisms' they were talking about. > > What about FIFOs and sockets? > > In fact, DBus is implemented over Unix sockets. FIFOs and sockets > don't define the format that will be used over them, they are just > channels of communication. DBus is a wire protocol, as they say in the > home page. It defines the format the methods and parameters should be > converted to make the communication viable, as well as an event system > so that applications can register interest in some activity. > > -- > A: Because it obfuscates the reading. > Q: Why is top posting so bad? > > --- > Denis A. Altoe Falqueto > --- I didn't know that. Thanks for clarification. :)
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 03, 2009 at 04:42:25PM -0200, Denis A. Altoé Falqueto wrote: > (...) > 4. There are other IPC mechanisms > > Yes, there are. But I think that each one has some drawbacks too. > CORBA, for example, is too heavy for simple use (Gnome developers can > tell a good story about that). XMLRPC needs a HTTP server or something > like that and the overhead of the communication protocol is not very > efficient for local use. Maybe there's another IPC mechanism that is > good, but maybe it doesn't have everything that DBus have (for > example, activation of daemons on demand). > > (...) I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets?
Re: [arch-general] conclusion: Another rant on arch way abuse and false promises
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote: > One thing I don't understand here is - why people crib that package B should > not have feature X. If you don't want that, ABS is for that. There are > plenty of packages which have additional dependencies like that mplayer(like > smbclient) or vlc(hal :) or lua). > > (snipped) The problem is that using ABS is impracticable if you have a big number of custom PKGBUILDs. OTOH, having packages with minimal dependencies isn't so great. During the (short) time I've used Gentoo, I noticed the consume of RAM is a little lower, but there isn't a big difference in performance. The problems arise when you compile packages with way to minimal dependencies, and later realize it was a mistake, and now you have to recompile lots of packages.
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 01:36:15PM -0200, André Ramaciotti da Silva wrote: > On Mon, Nov 23, 2009 at 04:06:34PM +0100, Heiko Baums wrote: > > Am Mon, 23 Nov 2009 12:16:46 -0200 > > schrieb André Ramaciotti da Silva : > > > > > I know, I know, they always come back. :P > > > My Arch installation is still in my HD, just in case. > > > > > > About disk usage, don't forget that arch keeps a cache of downloaded > > > packages. So I don't think Gentoo is in disadvantage here. My > > > installation uses 1GB less than Arch (both have basically the same > > > packages). It may not sound like a lot, thinking of the size most HD > > > have nowadays, but it's a 20% improvement. > > > > But you can delete the cached packages in Arch (pacman -Sc or pacman > > -Scc). ;-) If this is useful is a different question. > > > And you can delete the sources in Gentoo. Both distros are pretty OK here. > > > > I don't think compiling takes that much. If you're in a hurry, then > > > yes, it'll seem like forever. I installed in a weekend, basically the > > > same time I took to install Arch (because I install some packages, > > > then I remember of others, then others...). But it wasn't 48h > > > compiling, it was way, way less. > > > > On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile > > and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. > > while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and > > OpenOffice 12 hours. I did this several years until I had enough of > > this waste of time and found Arch Linux. > > > > Even if compiling only takes 48 hours. Installing it on Arch takes only > > a few seconds or maximum a few minutes. And compiling uses more > > ressources and thus more energy. > > Indeed, if I used KDE, I wouldn't use Gentoo. OTOH, Gentoo offers binary > packages of OpenOffice, Firefox and some other apps. However, from what > emerge tells me, firefox sources are one third the size of firefox-bin. As > Brazil isn't famous for its ultra-fast broadband, I can imagine certain > cases that compiling is faster. > > I agree with most of what you wrote, and I don't have the slightest idea > of how maintaining a Gentoo system in the long run is. I'm just trying it > and I like it so far, but keep in mind I've been using it for only one > week. > > This wasn't the first time I thought of trying Gentoo, so I installed it > to see how it is or I would be always thinking about it. When I get tired > of compiling, I'll go back to Arch with a better idea of its strengths. :) Just in case I left some of you wondering, yes, I'm back. I predicted it myself and I guess most of you also did. USE flags are nice, when they're playing along with you. When they're not, and you mixed packages from the stable and the unstable branch, then you have a problem. Though I resist to learn this, KISS is always better. It's good to be back :).
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 04:06:34PM +0100, Heiko Baums wrote: > Am Mon, 23 Nov 2009 12:16:46 -0200 > schrieb André Ramaciotti da Silva : > > > I know, I know, they always come back. :P > > My Arch installation is still in my HD, just in case. > > > > About disk usage, don't forget that arch keeps a cache of downloaded > > packages. So I don't think Gentoo is in disadvantage here. My > > installation uses 1GB less than Arch (both have basically the same > > packages). It may not sound like a lot, thinking of the size most HD > > have nowadays, but it's a 20% improvement. > > But you can delete the cached packages in Arch (pacman -Sc or pacman > -Scc). ;-) If this is useful is a different question. > And you can delete the sources in Gentoo. Both distros are pretty OK here. > > I don't think compiling takes that much. If you're in a hurry, then > > yes, it'll seem like forever. I installed in a weekend, basically the > > same time I took to install Arch (because I install some packages, > > then I remember of others, then others...). But it wasn't 48h > > compiling, it was way, way less. > > On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile > and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. > while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and > OpenOffice 12 hours. I did this several years until I had enough of > this waste of time and found Arch Linux. > > Even if compiling only takes 48 hours. Installing it on Arch takes only > a few seconds or maximum a few minutes. And compiling uses more > ressources and thus more energy. Indeed, if I used KDE, I wouldn't use Gentoo. OTOH, Gentoo offers binary packages of OpenOffice, Firefox and some other apps. However, from what emerge tells me, firefox sources are one third the size of firefox-bin. As Brazil isn't famous for its ultra-fast broadband, I can imagine certain cases that compiling is faster. I agree with most of what you wrote, and I don't have the slightest idea of how maintaining a Gentoo system in the long run is. I'm just trying it and I like it so far, but keep in mind I've been using it for only one week. This wasn't the first time I thought of trying Gentoo, so I installed it to see how it is or I would be always thinking about it. When I get tired of compiling, I'll go back to Arch with a better idea of its strengths. :)
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 02:49:19PM +0100, Heiko Baums wrote: > Am Mon, 23 Nov 2009 11:17:13 -0200 > schrieb André Ramaciotti da Silva : > > > I don't want to flame, but that's why I recently moved to Gentoo. > > Arch is one of the best distros I've used, but when you use a > > (primarily) binary distro, the number of choices you have is reduced. > > > > I don't blame the devs, though. They must make packages that appeal > > to a large number of users and Arch ends up with packages with a big > > number of dependencies. If you think about it, using a little bit > > more of disk space isn't a big problem compared to the problem some > > people would have if the default packages weren't compiled with these > > extra dependencies, because they would have to compile their own > > packages, defeating the reason to use a binary-based distro. > > > > I know, Arch has ABS, which is a great improvement compared to others > > binary-based distros, but it's still not perfect. Pacman doens't look > > for custom PKGBUILDs and automatically create the new packages based > > on them, and I guess it won't. Pacman wasn't meant to do that. > > > > You can make scripts based on pacman and ABS that will do this (I've > > made one shortly before changing distros), but then I realised I > > don't know all the ./configure options a package has, and I find > > documentation on this a little scarce. Using the 'USE' flags with > > emerge is much simpler in this aspect. > > I don't think that you will stay too long with Gentoo. ;-) > > It is right that you can reduce the dependencies a bit and that you are > more flexible by setting USE flags. As far as I recall the difference > between Gentoo and Arch Linux regarding the disk space is not > significant if there's a difference at all, but you will need a lot more > temporary disk space for compiling and it takes several days to compile > the whole system and every update takes much longer than on Arch Linux. > So I think "wasting" a bit disk space for dependencies which aren't > needed is better than wasting too much time for compiling the whole > system. That's why I switched from Gentoo to Arch Linux a while ago. On > Arch Linux you still have the same control over the installed packages > as you have on Gentoo. Don't overvalue the USE flags. > > There's optdepends to reduce the dependencies a bit as long as a > dependency can be made optionally. Otherwise more comfort for the common > users is better I think. > > And pacman and ABS are good as they are. There's still the > NoUpgrade option in pacman.conf if you build a package from ABS. > > Heiko I know, I know, they always come back. :P My Arch installation is still in my HD, just in case. About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement. I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less. I agree that with Arch you still have control over your packages, but USE flags make it easier. Somebody already went into the ./configure of all packages and put it in an easier way to do it. If programs could talk, emerge would be like: - I want my mplayer with samba and lirc support. - OK, I'll configure it this way, but then you also need to install this and this packages. While pacman would be something like: - I want my mplayer without samba support. - Wakka wakka wakka. Make a custom PKGBUILD then, wakka wakka. And finally, yes, there are optdeps, but pacman don't handle them as nicely it handles obligatory dependencies. If I install an optdep as an explicit installed package, when I uninstall the other package, the optdep will stay in my system. If I install it as a dependency, pacman will list it as an unnecessary dependency when I run pacman -Qdt. Andre
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 02:31:37PM +0200, Ionut Biru wrote: > On 11/23/2009 02:24 PM, Heiko Baums wrote: > > Am Mon, 23 Nov 2009 12:54:49 +0100 > > schrieb Tobias Powalowski: > > > >> Some depends are made for convenience, you can build the packages > >> with ABS without those depends, if they don't stop the program from > >> starting remove them and add then to ignore array in pacman.conf. > > > > But if I wanted to compile everything manually I would have stayed with > > Gentoo. ;-) > > > > Heiko > > like i said previous better to have that feature. Removing that feature > just because _you_ don't use and _you_ want to have minimal packages is > not the way. > > The only way is to get the build for those packages with ABS, remove > smbclient from your system and recompile those packages. Is simple and > is automatically thought makepkg. > > -- > Ionut I don't want to flame, but that's why I recently moved to Gentoo. Arch is one of the best distros I've used, but when you use a (primarily) binary distro, the number of choices you have is reduced. I don't blame the devs, though. They must make packages that appeal to a large number of users and Arch ends up with packages with a big number of dependencies. If you think about it, using a little bit more of disk space isn't a big problem compared to the problem some people would have if the default packages weren't compiled with these extra dependencies, because they would have to compile their own packages, defeating the reason to use a binary-based distro. I know, Arch has ABS, which is a great improvement compared to others binary-based distros, but it's still not perfect. Pacman doens't look for custom PKGBUILDs and automatically create the new packages based on them, and I guess it won't. Pacman wasn't meant to do that. You can make scripts based on pacman and ABS that will do this (I've made one shortly before changing distros), but then I realised I don't know all the ./configure options a package has, and I find documentation on this a little scarce. Using the 'USE' flags with emerge is much simpler in this aspect.
Re: [arch-general] Cannot set xattr
On Sun, Nov 08, 2009 at 09:23:11PM +0200, Priit Kivisoo wrote: > On Sun, Nov 8, 2009 at 9:14 PM, André Ramaciotti da Silva < > andre.ramacio...@gmail.com> wrote: > > > Thank you Thomas and Xavier. > > > > I just got a little worried though. Is there any reason for user_xattr not > > being enabled by default? > > > > I think it's because Arch doesn't use SELinux by default, as it's mostly for > ACLs. > > Priit I'm sorry, I think I wasn't very clear in my question. It isn't the default in Arch Linux because it isn't the default upstream, but why it isn't the default upstream? My worry is that it's somehow related to dataloss, but I couldn't find any search result about it, so I'll assume it's secure. In the worst case, I have my (daily) backups :) Thank you all.
Re: [arch-general] Cannot set xattr
Thank you Thomas and Xavier. I just got a little worried though. Is there any reason for user_xattr not being enabled by default?
[arch-general] Cannot set xattr
Hi all, I'm thinking of different ways to organize my files and xattrs seem a nice, standardized way to do so (don't ask me exactly what I'm trying to do, for I only have a slight idea). The problem is: I can't use them at all. I'm using the default kernel, which, according to /proc/config.gz has: CONFIG_EXT4_FS_XATTR=y and I'm using ext4, evidently. I've tried doing the following: $ echo 'asd' > test $ attr -s user.author -V andre test attr_set: Operation not supported Could not set "user.author" for test but, as you can see, it doesn't work. Running it as root doesn't work, too. I've also made a small C program, but it also fails to set the xattr, returning ENOTSUP (operation not supported), so it isn't a problem with 'attr'. I do have 'attr' from [core] installed so I don't know what else can be the problem. Thanks in advance, Andre
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 06:15:45PM -0500, Aaron Griffin wrote:
> On Thu, Oct 22, 2009 at 5:54 PM, André Ramaciotti da Silva
> wrote:
> > On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
> >> Sascha Siegel schrieb:
> >> >Hi,
> >> >
> >> >can someone tell my whats the reason for building the arch-kernel
> >> >with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
> >> >
> >> >Thank you!
> >>
> >> Optimizing for size sacrifices performance. Read the gcc
> >> documentation about the -O{1,2,3,s} options.
> >>
> >
> > I don't know if it is as simple as that. I recall reading somewhere that
> > under certain circumstances a binary optimized with -Os is faster than a
> > binary optimized with -O2.
> >
> > The reason for this is that a smaller binary may load faster than a big
> > one and cause less page faults.
>
> I really doubt the kernel is even close to the boundary for something like
> this
Agreed, especially as the kernel is loaded only once. I just went a little
bit off-topic while still on-topic. :)
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
> Sascha Siegel schrieb:
> >Hi,
> >
> >can someone tell my whats the reason for building the arch-kernel
> >with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
> >
> >Thank you!
>
> Optimizing for size sacrifices performance. Read the gcc
> documentation about the -O{1,2,3,s} options.
>
I don't know if it is as simple as that. I recall reading somewhere that
under certain circumstances a binary optimized with -Os is faster than a
binary optimized with -O2.
The reason for this is that a smaller binary may load faster than a big
one and cause less page faults.
