Re: Suggestions (how to choose mirrors)
Matt Domsch wrote: > Fedora has 244 public mirrors listed at the moment, and hundreds more > private mirrors. We have no way, nor really any desire, to know in > real time the load and network capacity of any connection between > each mirror and each specific user. Perhaps Akamai does, but that's > not a service we pay for. Just an idea: instead of (or in addition to) "blind" planning, based on net topology, geography, declared bandwith etc., yum could use an exploration approach: 1) choose a few good mirrors candidate 2) download one file from each of them (first file from first mirror, second file from second mirror, ) 3) gather speed statistics 4) reevaluate best mirrors according to statistics for the remaining files If the downloads are sorted by increasing size, you basically use the small ones to sample the mirrors and make a good choice for the big ones at the end of the list. (doing many downloads in parallel would be the real plus, so the slow and ugly mirror taking 1 minute for the 40kB file will complete while the good mirrors are serving you the kernel and openoffice.org) This would also be automatically optimal for local mirrors. Note that this is almost how P2P sharing works (just missing the sub-file granularity). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: even with gcc -g -O0
Chuck Anderson wrote: > On Mon, Feb 01, 2010 at 09:34:19AM +0100, Gianluca Sforna wrote: >> On Mon, Feb 1, 2010 at 7:18 AM, Chuck Anderson wrote: >>> Program received signal SIGSEGV, Segmentation fault. >>> playmonoi16 (dst=0x76ddc0, len=, >>>ch=) at mixasm.c:1746 >> Sorry for asking the obvious, but this hit me several times... is this >> mixasm.c file part of the sources you are compiling with -g -O0? if >> it's in a library your code is using, you also need to recompile that >> one with -O0. > > Yup, it is part of the source. Many/most of the files are actually > compiled as shared objects, but everything is using -g -O0. Someone > on #gdb thinks this is a gcc bug. One thing I would try is adding a int *lenp=&len; somewhere, just to make optimization a little more difficult for gcc. Maybe you avoid the bug, if there is one. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
seth vidal wrote: > I was just noodling around in the pkgtags db that I just posted about > and noticed that the a lot of pkgs have the 'Application' tag applied to > them. I could modify the appmarket plugin to use this information if it > is available. > > Coupling that data with tags like 'XFCE' it would be trivial to list > just xfce applications, for example. The database at https://admin.fedoraproject.org/pkgdb/apps/search/tanks would be more useful if you could search for "photoshop" and get "gimp, krita". Some more tags for "functionally comparable to" and the name of some well known programs for Windows or Macintosh would let people cope with the original names of Linux apps. Nero -> k3b, xcdroast Adobe Illustrator -> inkscape Adobe Reader -> evince, kpdf, okular This tags could also be added by the users, in a wiki like form. It is easy to build a good amount of useful information with a good specialized wiki, for example: http://www.thinkwiki.org/wiki/ThinkWiki -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
Kevin Kofler wrote: > Roberto Ragusa wrote: >> Some more tags for "functionally comparable to" and the name of >> some well known programs for Windows or Macintosh would let >> people cope with the original names of Linux apps. >> >> Nero -> k3b, xcdroast >> Adobe Illustrator -> inkscape >> Adobe Reader -> evince, kpdf, okular > > I think that would not fly for trademark reasons. I know there are sites > which do that kind of mapping and that some upstream projects advertise > their program as "comparable with (popular proprietary program XYZ)", but > they're treading on a very fine line legally. Isn't legally enough to just clarify that you are not XYZ? Maybe an additional "Photoshop is trademarked by Adobe" line has to be present. Laws are certainly stupid sometimes, but AFAIK the purpose of a trademark is just to guarantee the customer about the originality of what is buying. If I say "this is GIMP, a program similar to Photoshop", there is no reasonable possible confusion. I know that in the USA generic drugs are marked as "XXX acid, equivalent to Pfizer YYY commercial product", but on the other hand I know that CentOS was asked by Red Hat to remove any "Red Hat" string from their site... so maybe it could be as problematic as you are saying. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arithmetic coding in Fedora libjpeg (bug #639531)
Björn Persson wrote: > Tom Lane wrote: >> I believe that they'd be best advised to say "no", because at this point >> one of JPEG's principal attractions is near-universal compatibility. >> Throwing A/C into the mix will throw that away, for what really is a >> very marginal gain in compression efficiency. > > It's well known around the Internet that to achieve compatibility you should > be conservative in what you send and liberal in what you accept. Applied to > JPEG: Use only Huffman coding when encoding – except maybe if you know that > all > recipients can handle arithmetic coding – but support both encodings when > decoding. > Well said. Adding decoding support can do no harm. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing default setting of bash's hash table?
On 08/19/2011 01:24 PM, Roman Rakus wrote: > I have a question, if it is worth to enable this option by default? It > will not confuse some people, but can increase disk searching. Comments > welcome. Confusion can only happen in this particular case, I think: 1) you run a command and the cache is populated 2) you delete the command 3) you try to run the command again, in the same shell 4) you expect bash to find the command in another path, but get an error instead Correct me if I'm wrong. I remember having had to use "hash -r" one or two times in my life for this kind of issues. > RR Hey, I'm RR too. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
On 08/30/2011 09:24 PM, stan wrote: > On Mon, 29 Aug 2011 21:06:29 +0200 > Roberto Ragusa wrote: > >> Hi, >> >> it sometimes happens to me that X completely locks up, while the >> machine is still alive on the network. >> >> This is on F14, untainted kernel, nouveau driver, no 3D used, >> KDE desktop on a 32-bit machine with 8GiB RAM and PAE kernel. >> It typically happens when something is going to be drawn on >> the screen (a window pops up or virtual desktop change). >> >> I would like to open a bug, but I'm not able to attach any kind >> of usable log; dmesg says nothing, all I can say is that >> the screen remains frozen (including the pointer), the X >> server and the kernel keep doing some "SIG ALRM" stuff and >> any attempt to access the X server stalls the command (xrandr >> or xset, for example), in a Ctrl-C responsive way. >> >> Any idea? >> > I had this problem in F14 while using the stock kernel. When I > compiled a custom kernel it went away. While I made *many* changes, I > think the one that mattered was turning off SMP on my single core > system. I suspect, without proof, that the SMP code was occasionally > causing a race condition, and a deadlock. Other possible causes for > fix: moved to pre-emptable desktop, reserved 128 K low memory for > kernel, moved to deadline scheduler. > > You could open a bug against the kernel, but it has moved on so far > that it will probably languish. [now crossposting fedora, fedora-devel] Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. I had been compiling my kernels until many years ago, and I would like to stay with the distro's kernel. I hope that upgrading to F15/F16 will mix things up and solve this in some way. Opening a bug seems a waste of time. I'm cross-posting to fedora-devel, in case someone can suggest how to collect useful info to open a kernel bug. Thanks. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/03/2011 07:31 PM, Adam Williamson wrote: > To look at things at a higher level: it's clearly the goal of the > guidelines that any interested party (with sufficient basic knowledge) > who comes along and checks a Fedora package out of git should be able to > _understand it_, and this includes finding out where all the stuff that > goes to make up the package actually comes from. glibc spec clearly > doesn't achieve this goal; the casual browser is left looking at a > gigantic patch and a mystery tarball and wondering where they came from > and what they do, as I was. This makes glibc not at all raptor-proof, > and not very amenable to outside review or improvements, which is rather > against the spirit of an open source, community project. And the mind goes to a recent case of "obfuscation by merging patches". http://lwn.net/Articles/432012/ In that case RedHat acknowledged that a single giant patch is more difficult to understand and it confirmed that this was considered a feature (for commercial reasons); someone even started to debate if that could be considered a GPL violation, on the "source in preferred form" criteria. Regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
On 09/06/2011 01:18 PM, Reindl Harald wrote: > > Am 06.09.2011 13:10, schrieb Adam Jackson: >> On 9/1/11 5:05 PM, Roberto Ragusa wrote: >> >>> Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. >> >> Sure it is. Boot with maxcpus=1 on the kernel command line > > i would recommend "nosmp" because it really disables the kernel-smp code Ahem... what I meant is that it is not realistic for me to sacrifice one of the CPUs just to hope to get more stability. I intended the suggestion was "turn off SMP support if you have only one CPU". Thinking about it, the kernel is already no-SMP on systems with one CPU nowadays, right? Anyway, the problem happened again one hour ago, so I just decided to upgrade only the kernel to the one from F15 and hope for the best. If it happens again, I will then upgrade Xorg and Mesa. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
On 09/06/2011 11:14 PM, Roberto Ragusa wrote: > Anyway, the problem happened again one hour ago, so I just decided > to upgrade only the kernel to the one from F15 and hope for the best. > If it happens again, I will then upgrade Xorg and Mesa. Replying to myself in this old thread just to let google-searchers know that after upgrading my F14 installation to the F15 kernel 2.6.40.4-5.fc15.i686.PAE (including module-init-tools as a dep), the laptop has now an uptime of 15 days, no more X lockups. There were also more than 40 suspend/resume cycles without any failure, so it seems like the new kernel has fixed that issue too. As a regression, the ethernet driver sometimes fails to work after resume; it is a known bug for 3.0, easily fixed with modprobe -r e1000e; modprobe e1000e so I can live with it. (Of course I'm expecting a lockup minutes after sending this mail...) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unison formal review
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote: > https://admin.fedoraproject.org/pkgdb/acls/name/unison213 > https://admin.fedoraproject.org/pkgdb/acls/name/unison227 > https://admin.fedoraproject.org/pkgdb/acls/name/unison > > Instead of introducing yet another variation, can we somehow create a > single 'unison' package which covers all of the protocol variants? Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility. Isn't there a general policy "split into many rpms, when possible"? Having a single executable would be great (like rsync), but that is an upstream issue. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
On 03/24/2011 01:38 AM, Genes MailLists wrote: > On 03/23/2011 08:36 PM, Genes MailLists wrote: >> On 03/23/2011 07:58 PM, Kevin Kofler wrote: >>> Jochen Schmitt wrote: >>>> If you want to get firefox4 on Fedora 14 now, the only way is to use >>>> the private firefox4 repository on >>>> >> >> >>Or you can simply download it direct from mozilla.org and install it >> in /usr/local/ > > > Or in your home directory tree for that matter ... wont mess up any > official fedora install either ... :-) I usually go a step further: create a new user and install the tarball in his home directory. There is a ff3 user here, created some time ago. Time for a ff4 user... -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Beta RC1 Available Now!
On 04/09/2011 02:35 AM, Bruno Wolff III wrote:
> On Fri, Apr 08, 2011 at 13:19:55 -0700,
> Jesse Keating wrote:
>>
>> Would it make more sense to refer to these as "Alpha Candidate", "Beta
>> Candidate" and "Release Candidate" ? ac{1,2,3}, bc{1,2}, rc1 ?
>>
>> It does mean the name will change at each stage, but it should be more
>> descriptive as to what stage we're in.
>>
>> Thoughts?
>
> This seems reasonable. For those of us that worry about alpha and beta
> releases the old scheme made sense, but people that aren't involved in
> that could be confused and the scheme above would be clearer for that
> group. With the lists being index by search engines it isn't difficult
> for people who wouldn't understand the context to run across the terms,
> so it's reasonable to worry about it.
Just a data point. I usually read the list, but I'm not really involved.
One minute ago I saw this thread and my first thought was
"beta RC1? what's that?".
ac{1,2,3}, bc{1,2}, rc1 is a lot better.
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On 04/27/2011 08:48 PM, Dan Williams wrote:
> NM has had one for a while: 4 seconds. THe problem with longer is that
> then any time you do disconnect the cable or undock your laptop, NM
> would think that you were still connected for 10 seconds (or more) until
> if flipped over to wifi. So there's a conflict here between people that
> occasionally pull out the network cable to do stuff, and between people
> that dock/undock and move from wired to wifi.
But when you switch from wired to wifi you get a new IP so all your
connections are lost. Having to wait a few seconds more will not add
too much annoyance to the process. On the other end, if someone steps
on my cable, I think it is unreasonable that I only have 4 seconds
to fix it before losing my connections.
I think 4 seconds is too low. And 10 seconds too, I'd say.
Why not configurable? Or, why not to ask the user? ("wired carrier lost
for xx seconds, switching to wifi in xx seconds: button,
button")
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading from Fedora 14 to 15 -> some problems
On 05/28/2011 08:11 PM, Björn Persson wrote: > Adam Williamson wrote: >> the key is that we don't test any kind of real-world configuration, with >> anything other than default apps, actual user data in place and so on. > > And it shows. :-( My user account has been through many upgrades, and I've > grown accustomed to having various problems that don't show up in newly > created accounts. This is also my experience both at user level and at system level. At the user level, I just create a new user and see if I can replicate the problem. If not, a manual bisection of the user config files will typically lead to a solution rather quickly. (but KDE3->KDE4 was a difficult matter, in fact I still don't know how I can activate activities windows tabbing on kwin). At the system level, I install new Fedora releases from scratch on an an additional junk machine, try things around and after upgrading my real machines, I use the junk one as reference to replicate problems and diff configs. Used that recently for issues related to fonts and antialias settings (concluded that the new installation is bugged too). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is F15 unbackuppable? (RemoveSETUID)
Hi, which tools are able to backup the file capabilities which are now used in F15 because of RemoveSETUID feature? My tests with setcap/getcap (on F14) show that: - cp -a works - tar FAILS! - rsync -aFAILS! - MidnightCommander copy FAILS! Are these things fixed on F15? Am I right that every kind of remote backup solution based on tar or rsync has been broken for F15? (especially because the remote machine is not guaranteed to be F15 at all) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is F15 unbackuppable? (RemoveSETUID)
On 06/05/2011 12:32 PM, Ralf Ertzinger wrote:
> Hi.
>
> On Sun, 05 Jun 2011 11:39:02 +0200, Roberto Ragusa wrote
>
>> - rsync -aFAILS!
>
> rsync supports -X (for xattr) and -A (for ACLs), both must be
> given explicitly.
Thanks, rsync -X actually works (and I wonder why -X is not included
in -a, just as for cp).
I see tar has --xattrs. With tar -c it works (the tar file contains the
string with the value), but tar -x does not recreate the xattr.
By using strace I see that rsync does
open(".a.eWMgCy", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 1
fchmod(1, 0700) = 0
close(1)= 0
lstat64(".a.eWMgCy", {st_mode=S_IFREG|0700, st_size=0, ...}) = 0
llistxattr(".a.eWMgCy", 0x82bb0c0, 1024) = 0
lsetxattr(".a.eWMgCy", "security.capability", "\x01\x00\x00\x02\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 0
lsetxattr(".a.eWMgCy", "user.qqq", "www", 3, 0) = 0
utimensat(AT_FDCWD, ".a.eWMgCy", {UTIME_NOW, {1307265135, 0}},
AT_SYMLINK_NOFOLLOW) = 0
chmod(".a.eWMgCy", 0755)= 0
rename(".a.eWMgCy", "a")= 0
while tar -x does
mknod("a", 0700)= 0
setxattr("a", "user.qqq", "www", 3, 0) = 0
open("a", O_WRONLY|O_CREAT|O_LARGEFILE, 0700) = 4
close(4)= 0
utimensat(AT_FDCWD, "a", {{1307271119, 468295223}, {1307265135, 0}}, 0) = 0
setxattr("a", "user.qqq", "www", 3, 0) = 0
chown32("a", 0, 0) = 0
chmod("a", 0755)= 0
Why is tar not working? ("getcap a" prints nothing)
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is F15 unbackuppable? (RemoveSETUID)
On 06/09/2011 09:59 AM, Ondrej Vasik wrote:
> On Sun, 2011-06-05 at 13:50 +0200, Roberto Ragusa wrote:
>> On 06/05/2011 12:32 PM, Ralf Ertzinger wrote:
>>> Hi.
>>>
>>> On Sun, 05 Jun 2011 11:39:02 +0200, Roberto Ragusa wrote
>>>
>>>> - rsync -aFAILS!
>>>
>>> rsync supports -X (for xattr) and -A (for ACLs), both must be
>>> given explicitly.
>>
>> Thanks, rsync -X actually works (and I wonder why -X is not included
>> in -a, just as for cp).
>>
>> I see tar has --xattrs. With tar -c it works (the tar file contains the
>> string with the value), but tar -x does not recreate the xattr.
>>
>> By using strace I see that rsync does
>>
>> open(".a.eWMgCy", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 1
>> fchmod(1, 0700) = 0
>> close(1)= 0
>> lstat64(".a.eWMgCy", {st_mode=S_IFREG|0700, st_size=0, ...}) = 0
>> llistxattr(".a.eWMgCy", 0x82bb0c0, 1024) = 0
>> lsetxattr(".a.eWMgCy", "security.capability", "\x01\x00\x00\x02\x00
>> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 0
>> lsetxattr(".a.eWMgCy", "user.qqq", "www", 3, 0) = 0
>> utimensat(AT_FDCWD, ".a.eWMgCy", {UTIME_NOW, {1307265135, 0}},
>> AT_SYMLINK_NOFOLLOW) = 0
>> chmod(".a.eWMgCy", 0755)= 0
>> rename(".a.eWMgCy", "a")= 0
>>
>> while tar -x does
>>
>> mknod("a", 0700)= 0
>> setxattr("a", "user.qqq", "www", 3, 0) = 0
>> open("a", O_WRONLY|O_CREAT|O_LARGEFILE, 0700) = 4
>> close(4)= 0
>> utimensat(AT_FDCWD, "a", {{1307271119, 468295223}, {1307265135, 0}}, 0) = 0
>> setxattr("a", "user.qqq", "www", 3, 0) = 0
>> chown32("a", 0, 0) = 0
>> chmod("a", 0755)= 0
>>
>> Why is tar not working? ("getcap a" prints nothing)
>>
> Simply because tar does not store all the extended attributes. Just
> limited set of them. At the moment security.capability is not among
> them. Feel free to report a bugzilla against rawhide tar...
The problem is not only with the security.capability.
The user.qqq one is also missing (even if strace says it has been
attempted).
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is F15 unbackuppable? (RemoveSETUID)
On 06/08/2011 08:35 PM, nodata wrote:
> On 05/06/11 13:50, Roberto Ragusa wrote:
>> Why is tar not working? ("getcap a" prints nothing)
>>
>
> Have you got a bz#?
No, I will try to describe how to reproduce the bug
and open it (if noone is faster than me in doing so).
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kdevelop kdelibs false conflict
Hi,
yum is complaining about this dependency (on F14)
6:kdelibs-4.6.2-1.fc14.i686 has installed conflicts kdevelop < ('9', '4.1.80',
None): 9:kdevelop-3.5.5-1.fc12.i686
which is not correct, as kdevelop 3.5.5 is perfectly compatible with any kdelibs
(because it actually uses kdelibs3 instead).
I suppose kdelibs should conflict with kdevelop >=4.0.0 and <4.1.80.
(I'm not upgrading kdevelop as I prefer version 3).
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Name that Tree!
Mail Lists wrote: > On 02/13/2010 01:34 PM, Jesse Keating wrote: >> On Sat, 2010-02-13 at 11:07 -0500, Mail Lists wrote: > >> "Pre" or "Prerelease" was the name we used to use for Beta, so that's >> not saving any confusion there :/ >> > > > Ok - how about 13-dev ... or 13-frontier .. or 13-alpha .. or even > > 13-not-yet-beta willbe13 becoming13 towards13 almost13 roadto13 ... -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Name that Tree!
Bruno Wolff III wrote: > On Sun, Feb 14, 2010 at 11:57:51 -0500, > Mail Lists wrote: >> Maybe follow the kernel naming scheme .. >> >> 12 is the released version >> 12.x is what will become 13 .. >> 13.rc is now a release candidate (no longer development) >> 13 is released > > Anything related to the next release should have the release number of > the next release in it's name, not the current release. The 10.91 stuff > of the past was a pain, because you couldn't use that name to find the > corresponding parts of mirrors and the number changed for no good reason > along the way. Just calling it 13 and using the prerelease naming convention > for the rpm release info works much nicer. The obvious way to call something which is not 13, but is something a little less than 13 is 12.9, but I agree with you that it would be better to have 13 in the name instead of 12, so, logically: 12.0, 12.1, 12.2, 13.-2, 13.-1, 13.0, 13.1, ... negative numbers as secondary version. It may appear crazy, but it is indeed reasonable. (and while not trivial to sort, it's better than "13pre"<"13rc"<"13"). You could for example start alpha at -999, beta at -499, rc at -99 and have something like: 12.0, 12.1, 12.2, 13.-999, 13.-998, 13.-499, 13.-498, 13.-497, 13.-99, 13.0 It also provides an exciting "count-down to launch" concept :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Btrfs compression
Matt McCutchen wrote: > - Filenames with newlines will get mangled. > > - Hard links will be broken. > > - If a file is changed while the script is working on it, it may be > clobbered with the old contents. Similarly, if it is moved, it may > reappear in the old location. - Timestamps on directories will be modified. > The process should really be run using boot media, not on a live root > filesystem. This avoids the issue of manipulating the /bin/mv being > used. > > Here's the approach I would use, starting in the filesystem root: > > mkdir TEMP > (GLOBIGNORE=TEMP; mv * TEMP) > rsync -aAXH --remove-source-files TEMP/ . > rm -rf TEMP I agree with this approach. Better yet, copy everything on another disk, format and copy back again with compression enabled, so everything is well physically packed in the first (faster) part of the disk. Or, BTW, is the btrfs defragmenter good enough to let it do he job later? P.S. You just taught me what GLOBIGNORE is for. Thanks. It is anyway useless. I often do things like: mkdir OLD; mv * OLD and it works, with just a "can't move OLD inside itself" warning. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
Michael Cronenworth wrote: > Adam Williamson wrote: >> Only point to note is that it would definitely be a good thing to fix >> Bugzilla to merge the CC lists, I'll file a bug on that. =) > > Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 > > Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 But... but... if one of these two is declared duplicate of the other, their CC lists will not be merged... :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matt McCutchen wrote: > On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: > Oops, that's not completely true: pvresize currently is not smart enough > to move allocated data out of the area to be freed, according to its man > page. But you have other options, e.g., you can attach another disk, > create a PV on it, move the data there, rearrange the first disk as > desired, and move the data back, all while the system is running. > That's what's so fun about LVM. Even if pvresize doesn't move allocated data, you can do that with pvmove, and you do not need to move everything out of the PV, just the part you are going to truncate (PEs can be specified). I don't remember if pvmove can use the same PV as src and dest; in that case you could avoid the need of an extra disk when your PV is just "fragmented". -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Alasdair G Kergon wrote: > An example of the way I see it working is like this: > Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing > Logical > Volume LV1 containing the root filesystem. > You have a trigger rule saying "When you see the whole of VG1, activate LV1 > inside it" and another saying "When you see the filesystem with UUID X, mount > it." (Default rules can be generic of course, like 'activate any VG when you > see it' and 'activate any LV when you see it' and 'mount any filesystem when > you see it'.) Nice. You still need a timeout to avoid waiting for ever for the root filesystem to appear when one of the PV has been disconnected from the system. But this "lost hope" timeout is a lot better than the current "wait in any case" one. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Kevin Kofler wrote: > Richard Zidlicky wrote: >> However for some of the reports it is only the matter of someone looking >> at them as they contain the obvious solution to the problem. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=595165 >> https://bugzilla.redhat.com/show_bug.cgi?id=582013 > > The solution is not obvious at all: to include firmware, we need a license Ok, what about this one? Is this not obvious? https://bugzilla.redhat.com/show_bug.cgi?id=646157 After you spend half a day trying to understand why the fine installer is not making you the favor to do its work, you find the cause, you workaround the issue (by modifying py anaconda code _live_ and running a second instance on another tty), you open a bug and explain everything with all details, you just get a reply with a mildly disguised attempt to say that it is your fault. Then the bug is ignored (one months passed, 12 months left until self destruction). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Ralf Ertzinger wrote: > Hi. > > On Sun, 21 Nov 2010 09:26:58 +0100, Roberto Ragusa wrote > >> You still need a timeout to avoid waiting for ever for the root >> filesystem to appear when one of the PV has been disconnected from >> the system. > > If you cannot assemble the root file system, what is init supposed to > do instead of waiting forever? Print some kind of error "unable to find root (UUID=x)" and/or reboot or give you some kind of shell if there is enough rescue environment to let a prompt to be in some way useful. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
Kevin Fenzi wrote: > * Change FN-1 to just security and major bugfix. Nothing else allowed. So, if: 1) a package is updated because of a security problem 2) next day, FN+1 is released 3) next day, it is found that the fix in 1) has a very minor bug (e.g. typo in a string) 4) the string is not fixable anymore: no minor bugfixes for FN-1 If the regression is cosmetic/performance etc. it will be left unfixed, and we can't really describe this distro as "Linux, you know, that wonderful world where problems are rapidly fixes by lots of people around the world". We should more honestly say that Fedora as two level of support: - 6 months (any bug) - additional 7 months (serious bugs only) Next, the Fn-2 -> Fn upgrade process can be sacrificed. I personally like all kind of updates in a stable distro. Even major ones (such as KDE). I, as a user, will not be so stupid to update my presentation software a few minutes before the important meeting with the boss. I also trust the maintainers to not frequently push crap at me. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD support in Anaconda/F14
Camilo Mesias wrote: > > The output of sfdisk -l doesn't make it obvious if the disk is using > 4k sectors or is aligned in any particular way. [...] > > Disk /dev/sda: 7297 cylinders, 255 heads, 63 sectors/track > Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 > >Device Boot Start End #cyls#blocks Id System > /dev/sda1 * 0+ 63- 64-512000 83 Linux > /dev/sda2 63+ 7297- 7234- 58101760 8e Linux LVM > /dev/sda3 0 - 0 00 Empty > /dev/sda4 0 - 0 00 Empty IMHO it makes obvious that it is extremely bad aligned. C/H/S are all odd numbers (that is, not even). The important partition (sda2) starts at 63, which is off alignment. I don't know if your drive is one of the "let's shift every sector by one to make MSDOS..WINXP aligned". If the SSD is not doing tricks, this layout is misaligned. I partitioned my SSD in the following way. I forced 56 as sector/track (which is dividable by 8, 4096/512), so all partitions should come out 4KiB aligned. (used both CHS and sector output for clarity) No guarantee that my approach is right and that your SSD is wrong. :-) # fdisk -l /dev/sda Disk /dev/sda: 256.0 GB, 256060514304 bytes 54 heads, 56 sectors/track, 165383 cylinders Units = cylinders of 3024 * 512 = 1548288 bytes Disk identifier: 0x180397b2 Device Boot Start End Blocks Id System /dev/sda1 * 1 11484 83 Linux /dev/sda2 2 165383 2500575845 Extended /dev/sda5 2 476 718172 83 Linux /dev/sda6 477 3862057673700 83 Linux /dev/sda7 38621 42782 6292916 82 Linux swap / Solaris /dev/sda8 42783 9826383887244 83 Linux /dev/sda9 98264 165383 101485412 83 Linux # fdisk -l -u /dev/sda Disk /dev/sda: 256.0 GB, 256060514304 bytes 54 heads, 56 sectors/track, 165383 cylinders, total 500118192 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x180397b2 Device Boot Start End Blocks Id System /dev/sda1 * 5630231484 83 Linux /dev/sda23024 500118191 2500575845 Extended /dev/sda53080 1439423 718172 83 Linux /dev/sda6 1439480 11678687957673700 83 Linux /dev/sda7 116786936 129372767 6292916 82 Linux swap / Solaris /dev/sda8 129372824 29714731183887244 83 Linux /dev/sda9 297147368 500118191 101485412 83 Linux -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
Matt Domsch wrote: > On Wed, Jan 12, 2011 at 12:24:41PM +0530, Shakthi Kannan wrote: >> Greetings! >> >> I would like to know as to how long it takes to build a complete >> Fedora distribution, say i686, from .src.rpms. >> >> Are there any statistics available or is it possible to provide any >> info on the hardware specifications (RAM, number of processors, kernel >> used etc.), time it takes to build the complete Fedora distribution, >> and other build related statistics? > > It took my build system 96 hours to build all of rawhide (>10k > packages) for both x86_64 and i386. Builders are 10 Dell PowerEdge > 1955 servers, each with 2 sockets 3GHz Xeon 5160 CPUs (4 cores each), > 8GB RAM. Builders running Fedora 14. Interesting. So it took 2x4x10x96=7680 corehours to build 2 packages, at an average of 7680*60/2=23 coreminutes/package. And we get that on average one package takes 6 minutes on a 4 core machine. That makes sense. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
Tomasz Torcz wrote: > On Sat, Jan 15, 2011 at 07:38:21AM -0800, John Reiser wrote: >>This is a full rebuild of all >10k packages. Due to the RemoveSUID >>feature in Fedora 15, mock can no longer use tmpfs buildroots, meaning >>this run takes 4 days instead of <1. Progress? >> >> A slowdown by a factor of 4 is a high price to pay for the impact of >> RemoveSUID. >> I'd rather pay at most 30%, and not a factor of 4. > > That's the extreme corner case, caused by bug in tmpfs (lack > of filecaps?). Upstream kernel bug, I would say. Which filesystems support filecaps? Will the RemoveSUID feature reduce the number of filesystem usable in F15? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On 01/16/2011 07:57 PM, Kevin Fenzi wrote: > On Sun, 16 Jan 2011 10:14:33 +0100 > Roberto Ragusa wrote: > >> Which filesystems support filecaps? > > I don't know if there is a list anywhere... all the main ones do: ext*, > btrfs, xfs, etc. What about reiserfs? I've been using it everywhere for years. >> Will the RemoveSUID feature reduce the number of filesystem usable in >> F15? > > Depends on what you mean by "usable". Usable as filesystems that > contain packaged files? Usable as root partition, for example. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Kevin Kofler wrote: > I do not wish to stand for such a committee anymore Kevin, thank you for your attempts and for raising attention on the difficulties you have faced. If some of the time you save by not doing meetings will be spent on additional excellent technical contributions of yours, Fedora will actually gain something. So, if your decision is both positive for you and positive for Fedora, there is nothing to be too sad about. Respectfully, -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Super accurate timing?
Christopher Brown wrote: > On 2 May 2010 15:51, mike cloaked wrote: >> I saw that there is an interesting ultra precise timing code being >> developed - to possibly supercede NTP: >> http://www.cubinlab.ee.unimelb.edu.au/tscclock/ >> http://queue.acm.org/detail.cfm?id=1773943 >> >> Is this code being developed for Fedora at all? If so would there be >> any interest from Fedora (or Redhat) users if it was available I >> wonder? > > Not from my POV but the source is there in your first link Mike so why > not package it up? Is a kernel patch needed? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: > My point was that > any increased bureaucracy has not been generated with the intention to > reduce the amount of fun that developers have. Let me jump in just to say that I'm not a developer/packager, but it was my intention to become a contributor for Fedora. What scared me was just the huge level of bureaucracy. Submitting patches to the kernel 10 years ago was actually simpler than packaging a trivial rpm for Fedora is today. This is why I decided to not by a packager. I just try to help guys on the lists and open bugs (often ignored, I must add). Best regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
Miroslav Lichvar wrote: > The problem with the NTP project is that the development is closed. > Even the most trivial bugs take a lot of effort to fix. It's possible > to pay them to be a NTP forum member and increase the chances of them > accepting the patches, but that's not what I'd call an open > development. > > Also, we are carrying an intrusive (and not very easy to port) patch > that was rejected -- the power saving patch. I have to admit I was > hoping I could drop it one day if chrony was the default client. There was a "super accurate timing" thread a few days ago. Certainly much newer than the alternatives, so I suppose it is also more "immature". Still interesting, though. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use MALLOC_PERTURB_ ... or lose
Peter Jones wrote:
> Obsoletes is an awfully blunt instrument for this - it'd be a lot better to
> make change the debug.sh (and its .csh friend) have a conditional+config to
> decide whether to import the sysconfig bits based on either a) is this
> rawhide,
> and b) has the admin overridden "a" in the config?
Seems good.
Something like debug={enabled,enabled_if_rawhide,disabled}.
With enabled_if_rawhide as default option.
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
Matthias Clasen wrote: > Hey, > > early in the F13 cycle, we enabled the bytecode interpreter in our > freetype package, since the patents on that have expired last fall. > Unfortunately, it turned out that many free fonts don't actually benefit > from this, and actually look worse with the bci. The reason for that is > that without the bci, freetype uses its autohinter on all fonts, but > with the bci turned on, it only applies hints to fonts which have them, > and leaves other fonts alone. > > Behdad investigated the situation, and we have a plan to fix this, but > doing it properly requires enhancements in multiple places (freetype, > fontconfig, pango), and will not be ready in time for F13. My experience has always been that the autohinter is way better than all the bci stuff. I understand that the target of these modifications is to have the bci where available and the autohinter where bci info is missing. Will there be an option to say "always use the autohinter?"? If not, I would miss it badly. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
Ilyes Gouta wrote: > Hi Roberto, > >> My experience has always been that the autohinter is way better than >> all the bci stuff. > > Mine tells a different story, especially when dealing with standard' > fonts such as Arial, Tahoma and even Courier New. > > What I'd like to see is a true, fully featured font rendering > experience on the Linux desktop. Sadly, this goes through the bci > thing, a method for custom glyph control/reconstruction, which patents > expired recently. I'm well aware that many people have different tastes about font readability and that I'm probably out of the majority (who wants "like on Windows" rendering). This awareness was actually the reason of my post: to have guys remember that not everyone welcomes the bci. I don't mind defaults, I just need a flag to switch it off for me (with no recompilation). I don't want to find myself in the position of cursing the _expiration_ of a lame software patent. 8-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Xose Vazquez Perez wrote: > On 05/23/2010 04:23 AM, Tom Lane wrote: > >> I've been told (though this may well be inaccurate) that the LSB >> requires libjpeg 6b. If so, that would pose a problem for adopting >> the non-ABI-compatible version 8. In any case I'm not eager to force >> a recompile of everything that depends on it ... > > To be clear, this is fedora. > > RHEL is in the next door! Hmmm, isn't RHEL 5 actually many floors downstairs? ;-) RHEL 6 is not so far from here, ok, but the room appears to be still full of noisy and dangerous working tools. ;-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Ilyes Gouta wrote: > A merge is the most appropriate here. After all libjpeg-turbo just > offers a set of x86 specific SSE/MMX routines such as IDCT (maybe > huffman, but I didn't check that) that would be easily plugged into > ijg, but doesn't change the foundations (architecture and exposed > public API) of libjpeg. I'm personally quite surprised to discover that libjpeg has still no multimedia acceleration today. The number of impacted applications is huge: photo browsers (they make thumbnails), web browsers, ... Just loading the desktop background can imply the decompression of a big jpeg. And optimized IDCT code is not exactly something rare to find around. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
James Findley wrote: > Modern systems just don't take very long to spawn awk. Or sed. Or cut. > Or bash. IMO this sort of tradeoff between speed and ease of use hasn't > been appropriate in 20 years. > > It's really not at all uncommon for me to need to modify an init script. > There would be much rage if in order to do this I had to download the > SRPM, extract the init code, figure out what I needed to change, modify > it, recompile then install. Absolutely. I remember something similar with hal-disk-something, related to mount options. One day everything got switched to compiled code and manageability approached zero. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: > Jon Masters wrote: >> Didn't we "decide" that Fedora was intended for more technical users? I >> don't see many technical users crying out for a hammered shut init >> system where they feel like they have to go to their auto mechanic to >> attach the right magic dongle to fix it when it breaks. > > A really TECHNICAL user has no trouble editing a C program. :-) On a router? With no gcc installed? And with no disk space to install gcc? And with no network available? (because, you know, I'm fixing the router which is failing to boot properly) I hope your smiley face means you are joking. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: > Jeremy Sanders wrote: >> >> You're suggesting hammering shut the insides of linux to stop people >> playing around and reducing freedom - sounds like you want Fedora to be >> like the products of other large propitiatory systems. > > C code can be changed too, if really needed. But the point is that it should > not be necessary to edit code at all to get what's needed. Well, I really do not want to flame anyone, but please consider that the guy proposing the change already gave us pulseaudio, which promised the "it will do anything you do now, just easier" feature too. We then discovered that some _trivial_ things where lost: - having multiple independent sound cards - having control of the mixer - having sound with no user logged in ... should I also mention latency, CPU usage, stability,...? Come on, it took a couple of years to have a decently working audio system back. Now, should I really believe that the new "compiled but it will do anything" init system will be able to help me when ...don't know... I need to change firewalls rules and routing rules in the middle of the init scripts, because I have a multihomed internet connection and remote filesystems and I need the firewall closed and then opened in a way which is dependent on the IP I got from the ISP and I need a "sleep 5" in a proper place because the ADSL modem is still booting its firmware and I want some output printed to /dev/tty1 during boot and I want some filesystems to be mounted with "mount &" because they take time but only contain data not needed to boot and ? This stuff can be trivially done by a competent sysadmin with shell-based init scripts and vi. Linux must NOT be Windows. Linux must NOT be OS X. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: > Roberto Ragusa wrote: >> I need to change firewalls rules and routing rules in the middle of the >> init scripts, because I have a multihomed internet connection and remote >> filesystems and I need the firewall closed and then opened in a way which >> is dependent on the IP I got from the ISP > Ugh! Are you sure there's no better solution?! Kevin, this is not an exactly real scenario, but I wanted to say that sometimes it is useful to *hack* something in the middle of the init script for some reason. I know that no "sleep 5" should be there to wait for the firmware of the ADSL modem and so on... what I'm trying to say is that in some cases you need to do something dirty to work around a bug or to confirm a bug. For example, I had really bad luck with the rt2500 driver having weird crashes with the ordering and relative timing of "modprobe", "ifconfig up", "iwconfig". Understanding what the hell was happening during boot (and only during boot) made me add strange hacks into the scripts so to be able to describe the bug. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: > On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: >> Well, I really do not want to flame anyone, but please consider that >> the guy proposing the change already gave us pulseaudio, which promised the >> "it will do anything you do now, just easier" feature too. > > Ah, turning this into something personal. Love you too. This is not a personal attack and I want to explain. You will agree with me that pulseaudio caused a lot of complaints. (we do not discuss if motivated or unmotivated, here) That bad reputation unavoidably leads to weaker trust in your promised guarantees. The most painful parts of PA were mainly the underestimation of both "peculiar" use cases and impact of issues in related software (e.g. bugged alsa drivers). It is only natural to be worried about the same things (like lack of customizability) for this new init system. You *are* in a worse position than someone else when proposing a revolution in some critical part of the system. That's no personal offense. On the positive side you are now well aware of the risks you face, so you will probably play it better than someone else. I hope your new init system will be a great success and help you clean your name from the PA mess. I honestly hope so. >> We then discovered that some _trivial_ things where lost: >> - having multiple independent sound cards >> - having control of the mixer >> - having sound with no user logged in >> ... should I also mention latency, CPU usage, stability,...? > > You seem to have no idea what you are talking about. But anyway, let's > not turn this into a discussion about PA. Don't need another one of those. I've been personally been burned by these issues, to the point of going 90% of the way of removing PA from the system (I'm currently running the unrecommended system-wide instance, I manually restart it in some cases, I use often pasuspender and for some things I know I have to turn if off completely). But I'm still on F10 and I read that pulseaudio has become better. Maybe I will be positively surprised when upgrading to F13. >> Linux must NOT be Windows. >> Linux must NOT be OS X. > > Well I for one think we can learn a lot from the competition. Open your > eyes. There's a lot of good stuff in those other OS worlds, particularly > in the designs of MacOS X. There's still so much they do better than we > do. With "must NOT" I do not mean "we have to be far", I mean "we are not obligated to be near". In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), the fast-user-switching approach (the Unix way is to have multiple X servers). In conclusion, your innovation is certainly welcome in the Linux world, but disadvantages have to be properly weighted against advantages. If you only list advantages, people is rightly suspicious. You are trying to clarify things: I see you are replying to almost everyone on this thread and that effort has to be appreciated. You even replied to my mail, which you took for a personal attack (which, as I said as first sentence in this and the previous mail, was not). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: timevariant GUI elements (Re: systemd (Was Re: tmpfs for strategic directories))
Kevin Kofler wrote: > Roberto Ragusa wrote: >> In recent times some stupid (IMHO) ideas have been adopted in Linux >> just to copy what others do. Just as examples: the control of desktop >> widgets in KDE4 (functional GUI elements modified by a mouse-over???), > > I only know of 2 plasmoids triggering actions on mouse-over: Sorry, I didn't manage to explain me well. I'm referring to the vertical bar which popups at the left of right of _every_ plasmoid. The thing with the close button and which you can drag around to move the plasmoid. It is basically a window title bar done vertically. The bad part is that it popups on mouse movement and creates active elements (buttons) just under your mouse by guessing that you want them. If you have a crowded screen with overlapping windows and plasmoids, you get this popups in your way when you just want to click on a near window. Tooltips in general have this problem (uncontrollable creation of obstructions), but in this case the tooltip even contains clickable elements, so you have to be careful to not click them by error. Be_careful => be_slow_and_think => bad_GUI_concept. The folder view popping up you cited is another bad example (but I was not thinking about that). You say it's only visualization, but it changes the context, in the sense that now my dropping the icon has a new meaning (something randomly changed under my pointer). If the change happens just an instant before I'm releasing the button, my jpg will not go into Friends, but into Friends/DiscardedPhotos. So what should I do? Be careful to not park my pointer on any active area while I'm thinking about where to place my jpg; and every folder is now an active area; my desktop has turned into minesweeper. :-) I think the original idea from Apple was to use the spacebar to enter the directory. That is perfectly acceptable. In my opinion every "automatic" element (popups and tooltips) should only be allowed to show inactive things (better yet if the obstruction is not complete, for example, by using partial opacity and, if we want to be smart, increasing the opacity when the mouse is near, for legibility). In no case this thing must have clickable items. In no case this thing must intercept clicks: if I click on it the click should go to the elements it is covering (that is where transparency helps), because those elements have earned my attention for some time, before the appearance of the little intruder. The mouse pointer should be blended _below_ the tooltip. Tooltips should just be semitransparent post-it notes attached to my monitor. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: move libusb from /usr/lib to /lib
Rob Crittenden wrote: > Richard Hughes wrote: >> On 23 June 2010 09:50, Tomasz Torcz wrote: >>> “/sbin/upsdrvctl is used as the near final step in /etc/init.d/halt to >>> command >> That's completely bogus. You really don't want to just power down the >> machine like that -- it might lead to disk corruption and is certainly >> not a good idea for a server with a huge power load. >> >> I really don't think we want this feature in Fedora. >> >> Richard. > > You're misunderstanding what this does. It doesn't cut power to the > computer while its on. The process looks something like: > > - nut signals the UPS to shut down in x seconds (default 120) > - nut halts the machine > - after x seconds the UPS shuts down If the timeout is configurable, wouldn't be a reasonable option to move the command away from the final seconds and use a larger timeout? I mean, if the timeout is 5 minutes, the system has 5 minutes to shut down everything. It will probably do everything in 1 minute and poweroff. After additional 4 minutes the UPS will power down. I suppose these 4 minutes of "no-load" are not an issue. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
Al Dunsmuir wrote: > I would suggest doing PGO for the following: > > - Compression-type utilities (gz, zip, unzip, 7zip, etc), > especially those libraries used by RPM to generate/process deltas. and encryption stuff: openssl, openssh, md5sum, sha1sum, ... and data intensive stuff: rsync, gcc, grep, ... > - Helper routines used by yum to extract dependencies > > - X-Windows server and libraries used for 2D and 3D display such as > opengl, compiz, etc. and ghostscript, poppler, ... Everyone will easily suggest Firefox and OpenOffice.org. What about Java? (I mean: is the execution of the JIT-compiler part relevant enough to total speed?) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] The systemd unit files I'll post
Till Maas wrote: > On Thu, Jul 15, 2010 at 04:18:06PM +0200, Lennart Poettering wrote: >> On Thu, 15.07.10 08:58, Till Maas (opensou...@till.name) wrote: >> >>> On Thu, Jul 15, 2010 at 03:30:41AM +0200, Lennart Poettering wrote: >>> >>> And why should acpid go away? What is there that can be used instead? >> Used for what exactly? > > To react on ACPI events, e.g. when the lid of a notebook is opened[0] > or when the notebook is removed from a docking station. > >> upowerd handles this now. > > It looks like it is as bad documented as hal. At least the manpages on > freedesktop.org[1] did not provide any information about what one can do > with it. Acpid has a very good manpage that shows how one can easily > add scripts that react to any ACPI event. I have a use case which does not involve power management. Some keys on my Thinkpad generate ACPI events which I can assign to scripts run by acpid. For example the "ThinkVantage" button is mapped to 'sync' (acpid is one of the things which manages to work even on a half-crashed system), then I mapped some Fn-F[1-12] combinations to other system wide functions. One is mapped to kill -STOP/-CONT all running firefox processes, which I use to save battery while reading webpages, excluding the instants when I scroll or change tab. Another one helps with the display brightness control (detect brightness+ key -> run command to increase brightness). Another one is used to activate the screensaver/screenlock when walking away from the machine; maybe this one could have been done in a session context, but Fn-F1 is really well positioned to be reached by my fingers. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] The systemd unit files I'll post
Matthew Garrett wrote: > On Fri, Jul 16, 2010 at 09:42:33PM +0200, Roberto Ragusa wrote: > >> I have a use case which does not involve power management. >> Some keys on my Thinkpad generate ACPI events which I can assign >> to scripts run by acpid. > > Keys also all generate input events, and the /proc/acpi/events > interface is slated to die before too much longer. acpid is going to > have to die before too much longer, but it would be good to replace it > with something that can listen to arbitrary input events. I do not see events generated by those keys. That is, if I run "xev" I see events for some buttons (VolumeUp, Mute) but nothing for others (ThinkVantage and many Fn-F?? combinations). This is on Fedora-10, anyway. (...I know, I know, unsupported etc...) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE
On 08/14/2015 02:38 PM, Wei-Lun Chao wrote: > Hi, > > Is there already any discussion about: > rename arch name "noarch" to "all" > rename arch name "x86_64" to "amd64" > rename package name "kernel-PAE" to "kernel" > and even rename package name "kernel" to "linux" IMHO kernel-PAE -> kernel is reasonable, if the nonPAE is suppressed x86_64 -> amd64 is a good idea, as the architecture was created by AMD; dropping an underscore is nice too -- Roberto Ragusamail at robertoragusa.it -- 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: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE
On 08/16/2015 10:55 AM, Reindl Harald wrote: > > no the architecture was created by Intel > > AMD added the 64bit capabilities in a compatible way other than Intel itself > tried with Itanium which was not able to run i686 instructions and later > Intel was forced to license the AMD extensions Well, saying that the architecture was created by Intel is an evident "rewrite the history" exercise. You immediately contradict in the second sentence, where you describe the IA64 fiasco, and the adoption of AMD64 by Intel. Or maybe you think that "licensing the AMD extensions" is equivalent to "the architecture was created by Intel"? Let's recap how it really went: - Intel designed a new incompatible arch (IA64), it was useless at emulating the i386 and was a substantial market failure - AMD designed the AMD64, as an extension if IA32 - Linux was running on AMD64 immediately at day 0, as AMD had been giving around simulators for chips not created yet - Microsoft, who had already ported Windows to IA64, created an AMD64 version too - Intel tried to avoid the humiliating acceptance that their rivals did a better job than them, by going to extend the ia32 in a different way - Microsoft told Intel "I already did a port for you, you do not dare asking me another" - Intel released the "EM64T" architecture - Linus wrote a furious email saying that he had spent time studying the EM64T manuals only to finally realize that it could all have been replaced with just the sentence "it's AMD64" (differences are only found in little details) Nowadays some use "AMD64" and some "x86_64", with Intel preferring the second for obvious reasons. Having said that, the cost of change has got probably too high, so we will keep the current mix of AMD64 (used by BSD, Windows, Solaris, Java, Debian) and x86_64 (used by Linux, Fedora, SuSE, gcc). Regards. -- Roberto Ragusamail at robertoragusa.it -- 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 offline updates user experience
On 09/12/2014 05:47 PM, Richard Hughes wrote: > That's just not safe. Have you ever had firefox open and done a > firefox update? Widgets start disappearing, redraws start having weird > artifects and then after a little while it just crashes. Other > applications like LibreOffice behave the same. Anyone that says things > like "the old version of the library stays in memory" obviously hasn't > actually done much real-world GUI programming in the last decade, or > runs any kind of secure desktop system. You are basically saying that "modern" software is just breaking things which were perfectly solved decades ago. If applications would just use libraries correctly, the kernel would be able to let parts of deleted files be available for lazy loading. -- Roberto Ragusamail at robertoragusa.it -- 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: No more deltarpms by default
On 10/06/2014 07:57 PM, Reindl Harald wrote: > > oh no - don't tie all together for reasons which did not destory the world > over years - it is a damned good design that the part dealing with rpm > packages don't need to know anything aboutt delta rpms because the normal > packages are created before that step > And, going further on the same road... why don't we just find a way to locally produce the original rpm by downloading through rsync? Are compressed rpms completely impossible to diff efficiently by rsync? (losing a bit of compression efficiency could be acceptable if rpms became rsyncable) -- Roberto Ragusamail at robertoragusa.it -- 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: No more deltarpms by default
On 10/06/2014 07:25 PM, Reindl Harald wrote: > the last discussions suggested that the result needs to be *identical* to the > full RPM downloaded for not break signatures Bizarre design; the signature should protect the content (uncompressed), not the transport method (compressed). -- Roberto Ragusamail at robertoragusa.it -- 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 offline updates user experience
On 10/21/2014 10:02 PM, Lennart Poettering wrote: > Maybe > that's actually a strategy to adopt here: upload the encryption keys > into the firmware as efi vars, and then pull them out on next boots or > so (assuming that efi vars can be marked to survive soft reboots > without making them fully persistent...) Hmmm, surrendering your encryption keys to the only software part which you do not have control on? -- Roberto Ragusamail at robertoragusa.it -- 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: Supporting hibernation in Workstation ed., draft 1
On 2020-05-30 12:59, Iñaki Ucar wrote: If your swap is in a luks partition with a static passphrase (and secureboot is disabled) then hibernate works just fine. Actually, I can tell that a swap partition as an LVM volume living on a luks encrypted PV works perfectly fine. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-06-26 22:13, Justin Forbes wrote: Saying production on millions of systems is a bit misleading here, when you are talking about millions of systems at a single company. ...in a redundant configuration where losing a disk is tolerated by design and managing data that have very low vale (mostly pictures of cats and random chats). Filesystem quality must be measured in other conditions: have a Postgres on it, financial transactions, random blackouts, etc. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-06-27 10:47, Igor Raits wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-27 at 10:35 +0200, Roberto Ragusa wrote: On 2020-06-26 22:13, Justin Forbes wrote: Saying production on millions of systems is a bit misleading here, when you are talking about millions of systems at a single company. ...in a redundant configuration where losing a disk is tolerated by design and managing data that have very low vale (mostly pictures of cats and random chats). Filesystem quality must be measured in other conditions: have a Postgres on it, financial transactions, random blackouts, etc. Do you run postgres, financial transactions and random blackouts on your laptop / workstation? If so, isn't it just for testing purposes? No, but I do run on my laptop/workstation the same technologies that have been proven to be good for serious stuff. That is the fundamental Linux advantage, or at least has always been, and that's why I'm using Linux daily since when other people were waiting for the release of Win95. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 2020-06-30 15:34, Jóhann B. Guðmundsson wrote: Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. I've never really seen any reason to switch to UEFI since it appeared years ago. It just looked much more complicated (and buggy at the time), for no reasonable gain. I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new machines, for the simple reason that grub2 is really flexible; recently with GPT and code-EF02 bios boot partition. (GPT scheme 21686148-6449-6E6F-744E-656564454649: "Hah!IdontNeedEFI") In some cases I have complex setups where grub2 is installed two times, with the first one offering some entries, including chainloading the second one for additional entries (possibly on a different drive not always connected and which each operating system having their own grub2 and /boot). These things are either impossible with UEFI or would require learning everything again. I've seen lilo, grub and grub2, which has matured for years; we have finally started to understand it fully, we got the new blscfg thing too, and now... everything reinvented again? IMHO the firmware (BIOS/UEFI/something) should just be able to run a bootloader, everything else added is not an advantage. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 04:07, Nico Kadel-Garcia wrote: On Sun, Jun 28, 2020 at 6:21 AM Antti wrote: Hello, I'm in total opposition to this proposal as a long-time Fedora user. The btrfs is unstable and not ready for production. Most of what I'm about to write is admittedly anecdotal but it's the only file system in Linux which has actively and regularly caused me to lose data on desktops, laptops, servers and even on mobile phones when I haven't taken precautions and done regular backups. Something I don't have to actively do when using ext4 in my workstations and notebooks. We had similar excitement back when reiserfs was popular. My limited play with btrfs reminds me of reiserfs: feature-filled but fragile and unsuitable for "/" partitions. My experience with reiserfs has been very different. It was a wonderful filesystem, with journaling when nobody had it (ext3 did not exist, we only had ext2). It was able to raise the disk capacity of the disk (thanks to tail-packing) and the performance was great (I was able to immediately notice if the filesystem was ext2 or reiserfs, as soon as you deleted a big iso: reiserfs was immediate, thanks to extents vs blocks, I think). I've never had filesystem corruption on reiserfs even on very hard workloads. A specific episode remains in my mind: I had rsync hardlink based backups on a server with software RAID disks. One day I decided to delete about one year of backups, at four per day it was around 1000 directories, each of them with 100,000 files (heavily cross hardlinked, of course). To try to get good parallelism out of the RAID and the elevator, I submitted 1000 rm commands in background and then realized that I was deleting 100,000,000 files with an enormous lock and refcount stress testing on the fs. After a few hours, operation completed, no issue. The same production server was switched years later to ext4, since continuing with a mostly world-forgotten reiserfs option had no point. After a few days with ext4... fs corruption and data loss, simply because of an online expansion that was nothing special on reiserfs. Turns out ext4 kernel/tools combination was bugged. I've been able to find my comments on bugzilla (year 2012). https://bugzilla.redhat.com/show_bug.cgi?id=852833#c25 including this: (BTW, ...spent the weekend restoring a couple terabytes from backups...) (As a tribute to justice in the world, I want to say, so that search engines index it, that this system has been in production since 2005 on reiserfs and abused and resized without any similar issues; it was rebuild recently on new hardware and switched to ext4 and now I really risked to lose the data, as the remote versioned backup is also (resized) ext4, and the remote-remote backup is also (resized) ext4. I'm not complaining, but reiserfs really has a much worse reputation than actually deserved). -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 18:53, Michael Catanzaro wrote: The options we are seriously considering for our default going forward are (a) btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs all one big partition without LVM. This is being discussed in https://pagure.io/fedora-workstation/issue/152 One partition without LVM? Maybe labeling this partition C:\ The real solution would be to make wise usage of LVM, for example by not allocating 100% of the extents at the beginning (or even dm-thin) and/or using filesystems where a shrink is supported (I'm here blaming xfs for not having this, while ext4 has). -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 2020-07-01 23:04, Michael Catanzaro wrote: On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa wrote: The real solution would be to make wise usage of LVM, for example by not allocating 100% of the extents at the beginning (or even dm-thin) and/or using filesystems where a shrink is supported (I'm here blaming xfs for not having this, while ext4 has). Leaving space unallocated doesn't gain us anything because the user still has to manually resize both logical volumes and the partitions inside them. Our default needs to be something that doesn't require users to resize partitions. But those are things that can be done in a few seconds with one or two commands. Attempts to make easy things easier lead to making other things difficult: some not so inexperienced users will find themselves with their disk having only one big partition, no LVM, everything inside (system+data) and trying to decipher the suggestion found on a forum "with btrfs you can sort of format / without losing /home even if you do not have separate partitions". -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: booting successfully with read-only file system
On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote: Ubuntu's MOTD are well known and people seem to like them a lot. Fedora hasn't been making that much use of them. But I think we should in general. Do not follow Ubuntu on this too much. I've had a case of a machine with many short-lived incoming ssh connections where the performance bottleneck was the constant regeneration of the motd on each login. Sabotaging that stuff brutally was the only way to get back to good performance. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: urandom vs haveged
On 03/27/2012 05:23 AM, Gregory Maxwell wrote: > On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy wrote: >> So then the question is, if urandom is what's recommended, are faster >> substitutes just as good? If they are just as good, then why aren't they the >> first recommendation? And if this step is superfluous, then I'd suggest >> documentation be changed to eliminate the suggestion altogether. > > Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the > key and one of the secure block modes (e.g. aes-lrw or aes-essiv). > Then I fill the dmcrypt device with /dev/zero. This goes fairly fast, > filling the device with securely encrypted zeros. > > Then I drop the volume and set up luks normally. Nice trick. Does this saturate the disk speed? Last time I had to do this I compiled my own random generator, using some code from a research article. That was fast C code, when compiled for x86_64 with good gcc options the speed (>/dev/null) was 1.75GB/s (!!!). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [announce] yum: parallel downloading
On 05/20/2012 06:10 AM, Glen Turner wrote: > On 19/05/12 01:04, José Matos wrote: > >> The total number of connections should be the same, as far as I >> understand only the number of connections from a single host will be three. > > The risk is the rise in the maximum number of concurrent connections. A > server happily supplying 50,000 concurrent connections should not be > assumed to remain happy at 150,000 concurrent connections. Why do you think that there will be 150,000 concurrent connections? The difference could be that instead of - 50,000 concurrent users, each downloading one file you have - 16,667 concurrent users, each downloading 3 files The number of concurrent users is now lower because, well, each of them now completes a "yum update" in one third of the time. Reality could be different for several reasons (are users bandwidth limited? if the server bandwidth limited?), but the concept is fine and it has been perfectly expressed by Jose. >> Since it should be safe to assume that the downloads are independent >> events then there should not be any significant difference for busy >> servers. :-) > > I am afraid that I have missed your point here. I am somewhat blinded by > the use of the word "independent". I have a statistical background and > that word carries a meaning similar to "unrelated". 50,000 connections from different users are independent. 50,000 connections from 16,667 users doing 3 connections are almost as independent as before. Statistically, consider a random variable which is 0 (not downloading) or 1 (downloading). Compare: sum of N independent variables to: three times the sum of N/3 independent variables If N>>3, not only the average is the same, but higher-order statistics are only slightly higher. It is reasonable to say that the probability distribution is practically the same. An example: - is_downloading_one_file probability p=0.01 - number of users N=1,000,000 --> concurrent downloads: average=10,000 (sigma=~100) vs - is_downloading_three_files probability p=(0.01/3) - number of users N=1,000,000 --> concurrent downloads: average=10,000 (sigma=~170) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 02:38 AM, Gerry Reno wrote: > What does Fedora do currently, if anything, to optimize for solid-state > drives (SSD). > > Things like swap and logging can generate a huge number of writes. So I > suppose those should maybe be placed on a > rotating drive if one is available but if not does Fedora do anything to > reduce the amount of writes? Or is everything > related to SSD the responsibility of the user? I think Fedora aligns partitions to 1MiB boundaries and disables atime (with relatime), both things are good for SSD drives. Using tmpfs for /tmp is also ok. I've been using SSD drives for a couple of years, and in my opinion concerns about logs and swap are exaggerated. And having swap on SSD is a GREAT thing if you use hibernation. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 03:20 PM, Gerry Reno wrote: > Since I'm putting an SSD in my laptop this is important because the laptop > drive must be encrypted. I hope your CPU has AES-NI. A powerful i7 does AES at 50MiB/s (don't remember exactly, but below 100MiB/s) without AES-NI and about 900MiB/s with AES-NI. SSDs speed is usually around 250MiB/s, so AES-NI is required to maintain speed. Additional hint: I would avoid xts modes, as the speed is halved (450MiB/s) for not really convincing security reasons. I'm running AES with NI on a SSD and the CPUs are almost undisturbed by disk activities. Cipher name:aes Cipher mode:cbc-essiv:sha256 Hash spec: sha256 -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/26/2012 03:53 PM, Juan Orti Alcaine wrote: > I suspect it isn't working because "cryptsetup status > /dev/mapper/luks-uuid" does not say anything about discards. I think > it must say "flags: discards" > > Any suggestion? Directly testing if discard is working is doable, but not easy. Create a file with known content, and identify the hardware sector where it is mapped. You can use "filefrag -v", but you will have to compensate for all the layers (LV, PV, luks). Maybe it is easier to play with blktrace -o - --dev <<>> |blkparse -i - and identify the physical blocks you are writing your file to (sync, start blktrace, create the file, sync, stop blktrace). Then you read (with dd) the blocks from the crypted device (that is, the one which does not do any decryption, e.g. /dev/sda), delete the file and read the block again. If you get all zeros, discard is really working; if not, it is probably not working. Thinking about it: maybe blktrace is able to show you the discard command in its output... -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: Sandy Bridge -> lags, missing effects, ui-crashes
On 05/27/2012 07:54 PM, Reindl Harald wrote: > Hi > > i notice growing problems on F16 with "Intel Sandy Bridge" graphics > > * desktop effects in KDE partly not working (3D cube as example) > this worked well over months after upgrade from F14 to F15 and > > * sometimes the whole desktop hangs with display errors > like missing parts of windows solveable mostly by logout > but sometimes resulting in a complete system hang This happened to me too. Apparently in normal situations (scrolling a window, ...), I was almost suspecting a hardware bug. > * lags while starting applications or activate windows > of running apps Long lag (>5 seconds) while starting LibreOffice; the window is frozen at half-transparency while appearing and nothing else updates (clock is stuck). Fully updated x86_64 F16. Nothing logged by the kernel. It surely happened with more than one kernel: last time was today with 3.3.6-3.fc16.x86_64. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Another thing, possibly related, long lag (20 seconds) when coming out of suspend-to-ram; it seems to happen if I suspend on battery and resume with the AC power connected (ACPI interaction???). -- Roberto Ragusamail at robertoragusa.it -- 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 02:40 AM, Lennart Poettering wrote: > Heya! > > Please be aware that since the most recent systemd uploads /tmp is now > in tmpfs by default in Rawhide/F18. [...] > This will most likely lead to a problem or two with software that isn't > happy about /tmp being small. For example "sort". -- Roberto Ragusamail at robertoragusa.it -- 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 12:55 PM, Ralf Corsepius wrote: > On 05/31/2012 12:45 PM, Pádraig Brady 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. > >> So I'll patch sort to default to /var/tmp rather than /tmp. > This would mean introducing a bug. As far as I know: /tmp is for large data with no expectation of reboot persistence /var/tmp is for large data with expectation of reboot persistence tmpfs is for *small* data, so not a good choice for /tmp, it is certainly optimal for /var/run /var/lock and so on. I suppose that an additional small-tmp (e.g. /tmpram) could be useful for some programs currently using tmp for very small files. But these programs should be patched to deviate from a traditional Unix convention. As small (and short lived) files are equally fast on tmpfs or disk based /tmp, the whole effort is probably pointless. What would be a really good solution is the ability to specify very long timeouts for the VM write-back of a normal filesystem. Having /tmp dirty data in memory for 2 hours (and immune to normal sync commands) is the perfect approach. Have RAM? Use RAM. RAM pressure? Becomes a normal disk. (letting tmpfs swap is NOT the actually same thing, and I doubt you can set tmpfs much bigger than real RAM) It is quite easy to come up with use-cases where a small /tmp will be a problem. - any kind of temporary unpack/copy pattern, such as entering a tar.gz with mc, unpacking of installation files for (mostly proprietary) packages, ... - vmware uses /tmp/ram0 (immediately unlinked) as guest RAM backstore - I personally use /tmp for large files (including ISOs of DVD I want to burn and delete); maybe I'm the only one doing that... - I just discovered that my /tmp is currently 3.2GiB. The majority of the space is for /tmp/kde-myusername/konsole*.tmp (700MiB+520MiB+364MiB+305MiB+117MiB+), as I run konsole with unlimited scrollback buffer and some shells have easily been open for weeks. If the feature is implemented and activated by default, I will just turn it off and live happy. It will just be one more thing in the growing list of defaults that should have never been changed. But be prepared to more than "one or two" future bugs of the kind "Oracle can't be installed", "my backup program fails", "the machine slows down to a crawl and only a reboot fixes it", ... Best regards. -- Roberto Ragusamail at robertoragusa.it -- 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 03:55 PM, Pádraig Brady wrote: > Not all /tmp user-cases need to move to /var/tmp > > sort is special in this regard in that it only uses > external files when there isn't enough RAM. > I.E. is expects it to be slower (larger). Would you mind debating if anything else is "special"? # strings /usr/bin/*|grep ^/tmp$|wc -l 361 -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On 06/14/2012 04:54 AM, Kevin Kofler wrote: > Felix Miata wrote: >> Is "never" appropriate even if one's own experience is with 3 systems? 7 >> systems? 13 systems? 40 systems? Never say never, or always. ;-) > > That can widen the class of affected devices, but from there to "all Intel > WiFi" is still a long stretch. (For a starter, last I checked they didn't > even all use the same driver, but some legacy chipsets had legacy drivers. > Then AFAIK there are different code paths in iwlwifi for different device > generations, and also different firmware. And then of course different > hardware behaves differently. Plus, WiFi issues also tend to depend on the > exact configuration you're using, in particular on how the access point is > set up. And finally there can be interaction with other hardware or drivers > on the machine.) And do not forget the BIOS version, especially for suspend-related ACPI bugs. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: Sandy Bridge -> lags, missing effects, ui-crashes
On 05/29/2012 11:29 PM, Reindl Harald wrote: > the follwoing params making things better and stop especially > the lags most of the time, but on the same machine over a long > time was set to "pcie_aspm=force" and all i915 option at 1 > > "pcie_aspm=off i915.i915_enable_rc6=0 i915.semaphores=0 > i915.i915_enable_fbc=0" > > i think i have to mention taht VT-d is active in the BIOS and > i was wondering that it was stable because the combination of the > i915 options with VT-d (hardware supported virtualization IO) is > classified to be unstable No issues for a couple of weeks, after disabling VT-d in the BIOS, but there were kernel updates too, in the meantime. (And I now expect the problem to show up immediately after sending this mail) :-) -- Roberto Ragusamail at robertoragusa.it -- 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 08:06 PM, Brian Wheeler 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? Let's say it in this way: on a 4GB machine if the application uses the RAM, it works until (4GB+swap), but if the application uses a /tmp file, it works until 2GB! ...so using /tmp means you have less space... (facepalm) /tmp has always historically been a place where you dump large data. Disk size increases faster than RAM size. Switching disk storage to RAM storage by default is simply wrong. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pdftk retired?
On 03/06/2014 12:03 PM, Florian Weimer wrote: > On 03/06/2014 11:31 AM, Michael J Gruber wrote: > > pdftk has a hard dependency on GCJ because it's a C++ program that uses a > Java library (iText) through CNI. I once tried to rewrite the C++ part in > Java, but the existing command line parser is quite involved, so I didn't > quite get there. > > Switch to pdftk version 2 doesn't change the basic architecture of the > program. > > (We really want to get rid of GCJ.) What a pity that gcj (as a project) has been abandoned. Really interesting technology, now in some way reinvented many years later through Dalvik/ART. -- Roberto Ragusamail at robertoragusa.it -- 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: delta rpms - can we turn them off
On 06/29/2014 12:34 PM, drago01 wrote: > Well they should (or have some other source of documentation) ... the > config file isn't really the right place for documentation, given > that it does not get updated once you have edited it once ... you will > miss new options / changed semantics that way. This is way you keep an eye an any *.rpmsave, *.rpmnew and merge the differences (with a proper tool, like "meld"). -- Roberto Ragusamail at robertoragusa.it -- 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: LibreOffice packaging is a messy dependency graph
On 12/02/2015 02:42 PM, David Tardon wrote: > On Tue, Dec 01, 2015 at 02:20:34AM -0500, Dan Book wrote: >> I have run into this before and it was very confusing, it really should be >> a separate command from remove for when you actually want to remove what >> dnf thinks is now "unused". > > Why? Remove is the opposite of install. "dnf install foo" will install > package foo _and_ all its dependencies. So it is only logical that > "dnf remove foo" should remove package foo _and_ all its (unneeded) > dependencies. Maybe it is not so simple. There are dependencies with no use apart the main tool (tool requires tool-libs), but in some cases the dependency is useful on its own (e.g. fonts). So, I counter your reasoning with this: - dnf install foo (also installs bar) - dnf install bar (oops, already installed, good) - dnf remove foo (wow, why did it remove bar, I explicitly "installed" it yesterday!) Is dnf able to recognize that bar was "wanted" and not "accidental"? Regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
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). 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). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 09/13/2012 03:54 AM, Pádraig Brady wrote: > I'm going to err on the side of leaving sort(1) as is > and using /tmp by default, as detailed at: > http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html This is the perfect solution for all the people who will switch /tmp back to disk immediately after installation. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox / Thunderbird 17 ESR for Fedora 16/17
On 09/22/2012 01:02 PM, Julian Sikorski wrote: > Does it mean Fedora will stop shipping the latest FF/TB and stick to ESR > instead? Or is it for parallel-installation purposes? Assuming RHEL will have ESR (which is reasonable), either Fedora also stays with ESR (which is against the "first" F) or RHEL loses the "tested in Fedora" advantage. Is anyone going to clarify the strategy? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox / Thunderbird 17 ESR for Fedora 16/17
On 09/22/2012 09:03 PM, Matthew Miller wrote: > On Sat, Sep 22, 2012 at 07:37:13PM +0200, Roberto Ragusa wrote: >>> Does it mean Fedora will stop shipping the latest FF/TB and stick to ESR >>> instead? Or is it for parallel-installation purposes? >> Assuming RHEL will have ESR (which is reasonable), either Fedora also stays >> with ESR (which is against the "first" F) or RHEL loses the "tested in >> Fedora" >> advantage. > > Wait, which F is that? Freedom? I think both ESR and regular firefox > releases are 100% free and open source software. > > Or did you mean First? First :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 11/08/2012 02:41 PM, "Jóhann B. Guðmundsson" wrote: > You should file this as an RFE against yum since arguably this should be the > default behavior when users run "yum upgrade" but since the yum maintainers > have not done that already there has to be some gotcha- you are forgetting The process can fail in a lot of places, so having a script to blindly go ahead is dangerous. I would personally always use a script like this as a sequence of commands to be run by hand. If something happens in the middle of the steps, I have to solve it manually (e.g. removing some external rpm in case of dep problems). Hmm, I now see there is a "set -e" at the beginning. Still a little scary. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 11/09/2012 10:19 AM, drago01 wrote: > On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý wrote: >> On 11/08/2012 03:10 PM, Roberto Ragusa wrote: >>> >>> Hmm, I now see there is a "set -e" at the beginning. >>> Still a little scary.:-) >> >> >> Scary is only the idea. And only because we are not used to do rolling >> upgrades. Ask somebody from Debian experiance if this is scary ;) > > There are some upgrade tasks that you simply cannot do from within a > running system (ex: usermove). Serious question: why usrmove is not doable? If you have all the dirs in your path, and move executable files from one place to another, why should this fail? I managed to do a 32 bit -> 64 bit transition (you know, the "absolutely unsupported" upgrade) on a system which was running an entire KDE session. My upgrade commands (rpm, yum, bash, everything else) started 32 bit, then were mixed, then ended to be 64 bit. Usrmove appears simpler. Am I missing something? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:35 PM, Richard W.M. Jones wrote:
> On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:
>>
>> It could be argued that python is more suited to long lived programs:
>>
>> $ time /bin/true
>> real 0m0.002s
>
> Hmmm:
>
> $ echo '' > true.ml
> $ ocamlopt.opt true.ml -o true
> $ time ./true
>
> real 0m0.002s
> user 0m0.000s
> sys0m0.001s
>
> $ time /bin/true
>
> real 0m0.001s
> user 0m0.000s
> sys0m0.001s
>
> This seems about right to me: Both ocamlopt & gcc generate native
> x86-64 programs, but there's a small amount of overhead in the OCaml
> binary (initializing the minor heap of the GC).
Just for fun, let's see who is the worst.
$ cat >JavaTrue.java
public class JavaTrue {
public static void main(String[] args) {
System.exit(0);
}
}
$ javac JavaTrue.java
$ time java -cp . JavaTrue
real0m0.071s
user0m0.037s
sys 0m0.035s
Hmmm. Slow and with a lot of sys...
Let's try compiling it to native.
$ gcj -o JavaTrue JavaTrue.java --main=JavaTrue
$ time ./JavaTrue
real0m0.026s
user0m0.016s
sys 0m0.010s
Good improvement, but still quite slow.
(OT: what a pity gcj is abandoned... great project)
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
On 12/07/2012 08:26 PM, Mark Bidewell wrote:
>
> It underscores the need for the base OS or core to be absolutely as small as
> possible. FreeBSD provides a good model, small installed system customized
> with packages/ports. Personally I would like to see a three-level approach:
>
> Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc -
> moves the slowest.
> Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11,
> KDE/QT, GNOME, etc - moves faster.
> Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
>
> A major change to one level should cause a rebuild of higher layers to avoid
> the API issues you mention. Changes within a layer should be independent. I
> would propose change rates of:
>
> Level 1 - 12-18 mos
> Level 2 - 6-12 mos
> Level 3 - release as soon as stable packages are available.
IMHO it is not the "level" of things which is problematic.
I have no problem with rapid updates for the kernel (great for hardware
support and bug fixes), or for X11 (same reasons), gcc upgrades never
gave me problems, I like the fast updates to KDE.
There are two things which are problematic:
1) projects undergoing great revolutions. They are quickly absorbed
by Fedora and all the immaturity issues of the projects cast shadows on Fedora.
Two examples: GNOME 2->3, KDE 3->4; exactly the same problem, upstream
changing everything and users unhappy about the results (even if different
answers were given by KDE ("wait, we will readd what is missing") and
by GNOME ("forget what is missing, this is how it will be").
Obviously a regression of the desktop environment is not a small detail
for end users (read: "Fedora doesn't work").
2) revolutions at the system level. Things that replace other things and
everything changes: command line tools, GUIs, config files, logs, ...
Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld.
These projects sometimes have bugs (being in their infancy), often
are badly documented and are always completely unknown by end users; the
result is that things "do not work" and "who knows how this should be fixed".
In many cases the impact on the collateral utilities (dracut,
system-config-*, anaconda, ...) contribute to the chaos.
As a final consideration, the fixability of the issues is important.
I can easily revert to a previous kernel, I can less easily throw
away pulseaudio, and I can in no way fix GNOME 3.
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and
never stepping up as Fedora packager because too scared by the bureaucracy)
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dracut HostOnly or ConfigurationOnly?
On 09/06/2013 11:05 AM, poma wrote: > On 05.09.2013 16:51, Harald Hoyer wrote: > >> This Fedora release builds an initramfs tailored especially for your computer >> hardware. If you change your machine or partitions or significant hardware, >> you >> might have to boot with the "Rescue" boot entry and execute "dracut >> --regenerate-all". If you want your initramfs to be hardware independent, >> install the "dracut-nohostonly" rpm package. If you don't want rescue images >> at >> all (like in virtual machines), install the "dracut-norescue" rpm package. >> > > Package over here, package over there. > It's not so long ago called configuration. > Now if we want to configure something, we install a package. > Can someone package a pizza and send it here. > Oh wait, I forgot about prosciutto. > Install a prosciutto package, please. Using package installation as configuration is quite bizarre. Wasn't there a specific policy that installation and configuration are two different things? "You installed httpd, ok, so you have the stuff on your disk, but that does not mean it will run at next reboot, you have to configure and activate it explicitly". -- Roberto Ragusamail at robertoragusa.it -- 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: aarch64 bugs
On 03/23/2013 04:12 PM, Peter Robinson wrote: > On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote: > Eventually there will be hardware available but I'm not sure when > that will be as there's not been anything publicly announced. > Ultimately we're very much in the prep stages for a mass rebuild of > Fedora for aarch64 when we eventually get actual HW, at the moment a > build of something like gcc takes days. Days to build gcc? Wow. OpenSUSE managed to build the entire distribution without any hardware. Definitely not a trivial task. http://lists.linaro.org/pipermail/cross-distro/2013-March/000425.html -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/04/2013 06:35 PM, Adam Williamson wrote: > http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-passwords > > Well, that escalated quickly. And in one of the replies: http://it.slashdot.org/comments.pl?sid=3716785&cid=43628711 "I like the way Windows 8 addressed this problem. They added a button that looks like an eye on the right hand side of the password field to show the password as you've typed it. That seems like a better compromise than briefly showing the password characters." I think Microsoft just succeeded in teaching Linux something about security practices. And this is not something to be proud of. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On 05/06/2013 11:13 AM, Peter Robinson wrote: > On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera wrote: >> For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to >> be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. >> Packages for BlueZ5 will be available as soon as we figure out how to >> integrate a few downstream features that were in the Fedora packages. >> >> Bluez4 and Bluez5 are not parallel-installable, and incompatible, so >> other applications relying on Bluez4 will need to be ported by their >> respective maintainers. > > > Any analysis to what packages are affected, how many are yet to > support the new API and how hard it will be for them to be ported > over. > Impact on KDE? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On 06/08/2013 04:13 PM, Doug Ledford wrote: > > Yes, but none of these results show the .12s time that your first > noatime test run showed in your original post. If you are now saying > that atime is faster than noatime by about .005 to .010s, then these > results seem to show that. But your original post was from .019 to .12, > or a difference of .10+s. That was cache load time, not just the > syscall difference. Hmm, someone is misreading the results. I've reread multiple times, and I see a difference of 12s, not .12s. ---> real 0m12.645s ---> user 0m0.003s ---> sys0m0.159s And 12 seconds (elapsed, with 0.159s system) means 12s/5000=2.4ms which could only be explained with the auditing system doing fsync calls on its log files. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd 230 change - KillUserProcesses defaults to yes
On 05/27/2016 03:19 PM, Zbigniew Jędrzejewski-Szmek wrote: > This change was done for a reason: left-over session processes > are causing real problems. The original error was in fact having random processes spawned without user consent: configuration handlers, sound mixing, policy handlers and other stuff. Now a problem is solved by adding a new problem. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On 06/02/2016 01:04 PM, Lennart Poettering wrote: > Well. Let's say you are responsible for the Linux desktops of a large > security-senstive company (let's say bank, whatever), and the desktops > are installed as fixed workstations, which different employees using > them at different times. They log in, they do some "important company > stuff", and then they log out again. Now, it's a large company, so it > doesn't have the closest control on every single employee, and > sometimes employees leave the company. Sometimes even the employees > browse to the wrong web sites, catch a browser exploit and suddenly > start runing spam bots under their user identity, without even > knowing. Do you really want to support a disruptive change in default behaviour with such a specific use case? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24
On 10/04/2016 08:10 PM, stan wrote: > I think I can confirm this advice. I always run dnf manually from the > command line, in a VT logged in as root. And I can run X while doing > this and I've never had a dnf update issue. The problem with this is that the VT doesn't have a long history, so if you can't really see what dnf has done. (e.g. I visually search any rpmsave rpmorig rpmnew warning) -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Where are we going? (Not a rant)
On 12/08/2012 07:52 PM, Rahul wrote: > On 12/08/2012 01:48 PM, Roberto Ragusa wrote: >> (my two cents, as someone using Red Hat / Fedora daily since RH5.1, and >> never stepping up as Fedora packager because too scared by the bureaucracy) > > Can you be more specific? What sort of bureaucracy do you think is avoidable > in the current process? What would it take for you to get started? I do not have specific suggestions, as I actually do not know the process well, and even less the motivations behind each steps. I can only say that at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 23 steps are shown under "Becoming a Fedora Package Collection Maintainer". Some of them are technical and more or less unavoidable (koji, expiring certificates, scm, bodhi), others are more social (ask a review, introduce, inform upstream, get sponsorship), finally there is legal stuff (the CLA). My enthusiasm has never been powerful enough to overcome such an amount of static friction. I do not have a bag of packages to add to Fedora, so going through all the steps just to maintain one rpm or two is costly. I'm sure that after being "inside" the willingness to do more will raise easily, but the initial investment appears unjustified. Replying to random posts on the MLs or contributing patches to random projects is more appealing (write mail, click send, finished). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCE] xf86-video-intel 2.20.16
On 12/16/2012 09:44 PM, Reindl Harald wrote: > i notice slow gui / hangs after running KDE fpr many hours on machines with > VMware-Workstations guests in background which is a little bit strange on > IvyBrdige machines with 16 GB RAM and RAID10 > > after logout / login all is snappy again and note that the in the background > running VMs are not touched - so this must be graphics related at all Does vmware continuously blink something in the system tray? It could be tripping into this: http://lists.x.org/archives/xorg-devel/2012-November/034555.html It happened to me with psi, I fixed it with this patch, but my attempt to have it merged has been ignored completely... -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On 03/19/2013 02:38 PM, Bastien Nocera wrote: >> And Fedora switched to UTF-8 by default when exactly (was it even Fedora >> or a RHL decision)? > > Red Hat Linux 8.0: > http://en.wikipedia.org/wiki/Red_Hat_Linux I still remember how many things were broken in that moment (7.3 was considered the only usable RH for some time, and I have one machine still running it). RHL 8.0 also changed something at the font level (introduced antialias, maybe freetype?), so the entire text thing was a minefield. Anyway, that was the moment which demonstrated to me that Linux was so ahead of everyone else. I still fight today with iso88591 and cp1252 and utf16 BOMs and stupid crazy things which Windows and Java spread around, while everything in Linux always works perfectly. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
