[gentoo-user] Re: dev-ruby/json-1.8.0
On Fri, 06 Jun 2014 15:47:38 -0700, walt wrote: Is all of the above familiar to you? If not, you may need more help with managing multiple ruby versions. I find it a large PITA and I could use more help myself :) Could you explain what bothers you or where you would need help? Hans
Re: [gentoo-user] upower suddenly demands systemd
On Sat, 07 Jun 2014 01:30:33 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 06/06/2014 16:34, Gevisz wrote: After today's emerge-webrsync, I have found out that usual # emerge --update --deep --with-bdeps=y --newuse --ask world does not work, trying but being unable to emerge systemd. As I have found out, the reason for it was that upower suddenly decided that it needs systemd but, for some (lucky :) reason, it could not be emerged as my system uses OpenRC. The latest news said the following: UPower discontinued hibernate and suspend support in favor of systemd. Because of this, we have created a compability package at sys-power/upower-pm-utils which will give you the old UPower with sys-power/pm-utils support back. Some desktops have integrated the sys-power/pm-utils support directly to their code, like Xfce, and as a result, they work also with the new UPower as expected. All non-systemd users are recommended to choose between: # emerge --oneshot --noreplace 'sys-power/upower-pm-utils' or # emerge --oneshot --noreplace '=sys-power/upower-0.99.0' However, all systemd users are recommended to stay with sys-power/upower. However, that news did *not* say that without # emerge --oneshot --noreplace 'sys-power/upower-pm-utils' it is impossible to update the system even if you use xfce. The news item is a compromise as the problem you ran into is really a very minor one; it's the presence of systemd and two blocking upower packages that cause confusion. Extra points for the magic flame war-inducing trigger-word systemd - see the enormous threads here and on -dev for proof. ... As I said above, this simple package addition produces the magic flamewar trigger word systemd whcih always gets half the audience very very upset indeed. Thank you for pointing me out to that thread. Since I have made my mind in favor of OpenRC, I have stopped reading the systemd treads just to not be very upset. :) So, I missed that thread and thought that this issue is new. So the news item clarifies that you are not being forced to use systemd and explains the alternatives in a concise manner. Once you have that done, anything that comes next is simple routine portage blockers which you are expected to know how to deal with, and are not at all worthy of mention in a news item. Only after executing the last command, which installed upower-pm-utils and unistalled upower, the # emerge --update --deep --with-bdeps=y --newuse --ask world worked as desired. upower was not in my world file, so I think it's a some kind of a bug. It's not a bug and upower is not supposed to be in world. It's a simple dep library that portage will pull in if you have any other packages that need it. Keep it and upower-pm-utils out of world so that Samuli's next planned phase of this change in UPower will go smoothly. The reason for all the confusion is due to how portage works internally. Briefly, it sees you have a choice between upower and upower-pm-utils and usually ends up picking upower. It's similar to virtuals where portage doesn't know what you want so just picks the first in the list. If you want the second, then you have to emerge it yourself first, stopping portage from deciding. As I said above, this simple package addition produces the magic flamewar trigger word systemd whcih always gets half the audience very very upset indeed.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tue, 03 Jun 2014 14:38:34 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 14:30, J. Roeleveld wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. A proper solution would have been to have the upower ebuild select systemd as a dependency ONLY when the systemd useflag is set. And depend on upower-pm-utils when it is not set. -- Joost First of all, you should check your tone and secondly, you are clearly not understanding the situation as you are oversimplifying a complex situation. For example, Xfce works on non-systemd systems with any of these UPower versions, so forcing upower-pm-utils with USE=-systemd would simply be bogus. It is simply not true. I use xfce and still I could not update my world just because some systemd-dependent guys think that they can force everybody else to use it. If you are looking for a system that decides everything for you, and doesn't give you options what to install, you are propably better off using some binary distribution with smaller set of possibilities. I look for the system that can clearly update itself, not trying to sell me something that I do not need after I have clearly decided for the default package before.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Sat, 7 Jun 2014 11:32:00 +0300 Gevisz gev...@gmail.com wrote: On Tue, 03 Jun 2014 14:38:34 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 14:30, J. Roeleveld wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. A proper solution would have been to have the upower ebuild select systemd as a dependency ONLY when the systemd useflag is set. And depend on upower-pm-utils when it is not set. -- Joost First of all, you should check your tone and secondly, you are clearly not understanding the situation as you are oversimplifying a complex situation. For example, Xfce works on non-systemd systems with any of these UPower versions, so forcing upower-pm-utils with USE=-systemd would simply be bogus. It is simply not true. I use xfce and still I could not update my world just because some systemd-dependent guys think that they can force everybody else to use it. Please try to understand the situation before blaming any parties; systemd-dependent guys haven't even been involved in all of this, so, I'm not sure how you can perceive this as a matter of force by them. It is a logical consequence of pm-utils' end-of-development life cycle. If you are looking for a system that decides everything for you, and doesn't give you options what to install, you are propably better off using some binary distribution with smaller set of possibilities. I look for the system that can clearly update itself, not trying to sell me something that I do not need after I have clearly decided for the default package before. The system is selling you a choice; pick one or the other, it's not a merge systemd but rather a block systemd against the other choice. The system cannot merge something until you make that choice; if you are looking for a distribution that can update itself, Gentoo might not be the right distribution for you as it is all about providing choice. Compare this to other distributions which make the choices for you; interesting to note, a lot of those distributions picked systemd, instead of it being forced Gentoo actually blocks it for you to choose. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] OT: Mapping random numbers (PRNG)
On Sat, Jun 07, 2014 at 12:03:29AM +0300, Matti Nykyri wrote:
On Thu, Jun 05, 2014 at 10:58:51PM -0500, Canek Peláez Valdés wrote:
On Thu, Jun 5, 2014 at 9:56 PM, meino.cra...@gmx.de wrote:
Hi,
I am experimenting with the C code of the ISAAC pseudo random number
generator
(http://burtleburtle.net/bob/rand/isaacafa.html).
Currently the implementation creates (on my embedded linux) 32 bit
hexadecimal output.
So it's a 32 bit integer.
From this I want to create random numbers in the range of [a-Za-z0-9]
*without violating randomness* and (if possible) without throwing
away bits of the output.
You mean *characters* int the range [A-Za-z0-9]?
Well this isn't as simple problem as it sounds. A random 32 bit integer
has 32 bits of randomness. If you take a divison reminder of 62 from this
integer you will get only 5,95419631039 bits of randomness
(log(62)/log(2)). So you are wasting 81,4% of your random data. Which is
quite much and usually random data is quite expensive. You can save your
precious random data by taking only 6 bit from your 32 bit integer and
dividing it by 62. Then you will be wasting only 0,8% of random data.
Another problem is alignment, but that is about mathematical correctness.
How can I do this mathemtically (in concern of the quality of output)
correct?
The easiest thing to do would be:
The easiest is not mathematically correct though. Random data will stay
random only if you select and modify it so that randomness is preserved.
If you take devison reminder of 62 from 32 bit integer there are 69 273
667 possibilities of the reminder to be 3 or less. For the reminder to 4
or more the number of possibilities is 69 273 666. In mathematically
ideal case the probability for every index of the list should be same:
1/62 = 1,61290322581%. But the modulo 62 modifies this probability: for
index 0-3 the probability is 69 273 667/2^32 = 1,61290324759%. And for
indexes 4-61 the probability will be 69 273 666/2^32 = 1,6129032243%.
If you wish not to waste those random bits the probabilities will get
worse. With 6 bits of random the probability for index 0-1 will be 2/64
and for 2-63 it will be 1/64. This is a very significant change because
first and second index will appear twice as much as the rest. If you add
2 characters to your list you will perfect alignment and you can take 6
bits of data without it modifying probabilities.
If you are looking a mathematically perfect solution there is a simple
one even if your list is not in the power of 2! Take 6 bits at a time of
the random data. If the result is 62 or 63 you will discard the data and
get the next 6 bits. This selectively modifies the random data but keeps
the probabilities in correct balance. Now the probability for index of
0-61 is 1/62 because the probability to get 62-63 out of 64 if 0.
---
#include time.h
#include stdio.h
#include stdlib.h
#define N (26+26+10)
static char S[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J',
'K', 'L', 'M',
'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z',
'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',
'k', 'l', 'm',
'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z',
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
int
next_character()
{
// Use the correct call for ISAAC instead of rand()
unsigned int idx = rand() % N;
return S[idx];
}
so modify the next_char function:
char next_character()
{
static unsigned int rand = 0; //(sizeof(int) = 32)
static char bit_avail = 0;
char result = 0;
char move_bits = 0;
char bits_moved = 0;
do {
if (!bits_avail) {
// Use the correct call for ISAAC instead of rand()
rand = rand();
bit_avail = 32;
}
move_bits = bits_avail = 6 ? 6 : bits_avail;
result = move_bits;
result = (result | rand (0xFF (8 - move_bits))) 0x3F;
bits_avail -= move_bits;
bits_moved += move_bits;
rand = move_bits;
} while (bits_moved != 6 result 61);
return result;
}
Well actually it looks simpler if you break this like this:
unsigned char get_6bits ()
{
static unsigned int rand = 0; //(sizeof(int) = 32)
static char bits_avail = 0;
unsigned char result = 0;
//get 2 bits 3 times: 32 is devidable by 2
for (int i = 0; i 3; i++) { // --std=c99
//Fill buffer if it is empty!
if (!bits_avail || bits_avail 0 ) { //if bits_avail 0 it is
an error!
Re: [gentoo-user] How to extend the tmux status 'title' for each pane or window
On Tuesday 03 Jun 2014 15:16:56 Stroller wrote: On Tue, 3 June 2014, at 6:59 am, Mick michaelkintz...@gmail.com wrote: … I have: … status-left #[fg=blue]#T … status-right #[fg=blue][#S] … Thanks Stroller, On the left status bar I see this: [0] 0:bash* with one window open. As I create more windows it adds to it like so: [0] 0:bash 1:bash- 2:bash* The right hand side shows the prompt, or command being run, but not all of it if it is too long. … status-left [#S] … status-right #22T %H:%M %d-%b-%y It looks to me like I've merely swapped left and right panes because, presumably, I thought it looked better that way. And I've removed the clock - that's one way you could reclaim some screen space. Right, on my default setup the clock is on the right, the number of windows on the left and the title in the middle. As is the title shows: root@compaq:/usr/src/l instead of root@compaq:/usr/src/linux. This is what I mean of it being cut short. [snip ...] As I say, I don't seem to be firing on all cylinders right now, but it doesn't look to me like the commands being run are shown where you say they are, not on the far right, at least. I think they're shown in the *middle* section of the status bar. Yes, they are shown in the middle, but on a 82x25 pixel terminal the title is displayed about 2/3 towards the right of the status bar, right against the clock. See attached screenshot. Running tmux set -g status-right #32T removed the clock and increased the real estate for the title bar. Thanks again Stroller. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] OT: Mapping random numbers (PRNG)
Am Sat, 7 Jun 2014 12:19:11 +0300
schrieb Matti Nykyri matti.nyk...@iki.fi:
On Sat, Jun 07, 2014 at 12:03:29AM +0300, Matti Nykyri wrote:
[...]
unsigned char get_6bits ()
{
static unsigned int rand = 0; //(sizeof(int) = 32)
Just an itty bitty nitpick: since you already require C99 as per the for loop
below, you might as well use uint32_t (from stdint.h) instead of assuming that
sizeof(int) == 32 :) .
static char bits_avail = 0;
unsigned char result = 0;
//get 2 bits 3 times: 32 is devidable by 2
for (int i = 0; i 3; i++) { // --std=c99
//Fill buffer if it is empty!
if (!bits_avail || bits_avail 0 ) { //if bits_avail 0 it is
an error!
// Use the correct call for ISAAC instead of rand()
rand = rand();
bits_avail = 32;
}
result = 2; //move two bits to left.
result = result | (rand 0x3); //add two least signifigant
bits to the result.
rand = 2; //move two bits to right.
bits_avail -= 2;
}
return result; //result has 6 bits of random data...
}
char next_character()
{
unsigned char idx = 0;
do {
idx = get_6bits();
} while (idx 61);
return S[idx];
}
Very simple :)
[...]
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
signature.asc
Description: PGP signature
[gentoo-user] Logitech C920 HD Pro Webcamera ... view: YES record: NO ?
Hi, the Logitech c920 HD Pro webcam is able to deliver 1920xq080x30fps (H.264). Now I am trying to display (watch) and record the video stream. Currently I am using guvcview. Most of the time watching is not an problem: no video delays, no frame drops, no ultra low fps...wonderful! But beware of pressing the record botton... KABOOM! guvcview ends with an error message, which does not say anythong to me...: (guvcview:19104): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed initiating video file context STREAM: add stream 0 to stream list I tried cheese which interestingly dies similiarily... Since there a zillions of things to tweak with the video and audio setting I still hope that someone got this nice camera running and recording with full hd and audio ? Any ide to fix that? Best regards, mcc
[gentoo-user] Re: Logitech C920 HD Pro Webcamera ... view: YES record: NO ?
meino.cramer at gmx.de writes: the Logitech c920 HD Pro webcam is able to deliver 1920xq080x30fps (H.264). Now I am trying to display (watch) and record the video stream. Currently I am using guvcview. This 'gstreamer tidbit' might be useful to you: http://www.oz9aec.net/index.php/gstreamer/473-using-the-logitech-c920-webcam-with-gstreamer hth, James
Re: [gentoo-user] Re: Logitech C920 HD Pro Webcamera ... view: YES record: NO ?
James wirel...@tampabay.rr.com [14-06-07 17:40]: meino.cramer at gmx.de writes: the Logitech c920 HD Pro webcam is able to deliver 1920xq080x30fps (H.264). Now I am trying to display (watch) and record the video stream. Currently I am using guvcview. This 'gstreamer tidbit' might be useful to you: http://www.oz9aec.net/index.php/gstreamer/473-using-the-logitech-c920-webcam-with-gstreamer hth, James hie James, Thanks! :) I found it before...this is the updated, more recent version: http://www.oz9aec.net/index.php/gstreamer/487-using-the-logitech-c920-webcam-with-gstreamer-12 It works so far as I can view the stream...but cannot trigger a record. (Background: I am watching crows with this cam, and if anything interesting happens I want to press REC to capture everything to disk) Bets regards, mcc
[gentoo-user] Re: Logitech C920 HD Pro Webcamera ... view: YES record: NO ?
meino.cramer at gmx.de writes: the Logitech c920 HD Pro webcam is able to deliver 1920xq080x30fps (H.264). Some interesting notes and comments at the bottom of this page: http://www.ideasonboard.org/uvc/ Also, in the past, I have found the best comments on various camera hardware in the relevant kernel driver. Sometimes that is a unique driver, other times it is a unified kernel driver for a similar group of video cameras. Sometimes you can go way back to where the kernel driver for a given video camera first appeared (got supported) in the linux kernel for detailed information on the limitations of a given piece of hardware. Often, the poorer performance on Linux, was intentionally due to the actions of the manufacturer, particular on max frame rate, bit minipulations and other key parameter settings of the cameras. Once folks learned the protocols (decoded them) on windows, they would make those adjustments with windows software and reverse engineer the driver software so as to be able to support various linux drivers. Logitech is very reasonable (at least compared to other vendors) but even there newer hardware rarely works with the best of a given feature set, until the product has been out for a while. If not, Logitech should have a published interface specification so and to make reverse engineering not necessary? Dunno know the specifics on the model your listing, as I've been out of that 'game' for a while now, but all those tigers still have the same stripes Good hunting! hth, James
[gentoo-user] Re: Logitech C920 HD Pro Webcamera ... view: YES record: NO ?
meino.cramer at gmx.de writes: I found it before...this is the updated, more recent version: http://www.oz9aec.net/index.php/gstreamer/487-using-the-logitech-c920-webcam-with-gstreamer-12 Thanks, I do not keep current with video anymore It works so far as I can view the stream...but cannot trigger a record. You cannot record with any of several application or just one in particular? It seems like I vaguely remember somewhere a howto, to setup a generic small ram drive to 'enhance' the performance of recording on a linux system, but I cannot find the link right now. I use to have problems with resources where if much of anything else was using the HD, even though (record) bandwidth of the mobo sata chip and the drive were no where near the limit, I'd have problems with sustained video recording. Buffer overload? Registers can't keep up? Commerical system all have CAM (Content Addressible Memory) to put the memory on steroids for all sorts of low latency performance capabilities and gains I never tracked down that problem nor found a fix that was not too expensive. My guess is it would be a customized, minimized, highly tweaked kernel that would work best for video recording and latency-bandwidth issues, etc. I was working on multiple medium resolution streams. A singular, hi-res video stream might be even more problematic. It would be an interesting test to put your recording efforts onto a multi disk (raid) array specifically tuned for write speed and see if that fixes your issues? Drop the quality way down and see if you can record then. It that works, then what I just wrote about is your demon. If not, then it's a bug, syntax,decoding or other algorithmic issue. Dunno. (Background: I am watching crows with this cam, and if anything interesting happens I want to press REC to capture everything to disk) If you are drawing a paycheck, for watching crows, or just maximizing crop yeilds, you are my new, favorite hero... Black Crows are one of my favs.. Red-headed woodpeckers are a close second... (we have lots in Florida) hth, James
[gentoo-user] Re: dev-ruby/json-1.8.0
On 06/07/2014 12:56 AM, Hans de Graaff wrote: On Fri, 06 Jun 2014 15:47:38 -0700, walt wrote: Is all of the above familiar to you? If not, you may need more help with managing multiple ruby versions. I find it a large PITA and I could use more help myself :) Could you explain what bothers you or where you would need help? Hi Hans. The annoying problems occur when updating ruby-related packages. For example, I (want to) use only ruby19: #grep RUBY /etc/portage/make.conf RUBY_TARGETS=ruby19 In spite of that, portage often insists on installing other versions of ruby, rdoc, rubygems, and you already know the others. AFAICT, the other versions of ruby are dragged in by old ruby packages that were installed before I started using RUBY_TARGETS (because I didn't yet know about RUBY_TARGETS), I discovered all of this by grepping for ruby in /var/db/pkg but it took me a long time to get it sorted out, and I don't expect that a gentoo beginner could do it. (OTOH maybe a gentoo beginner wouldn't care about installing multiple ruby versions :) Thanks for taking the time to read gentoo.user and even more thanks for being a gentoo dev :)
