Re: [SLUG] Re: [chat] yet another reason to advocate Linux
Don't let this become a Linux only thing - whether one thinks Free as in FSF, open source as in the OSI or supports proprietary Microsoft...child labour is abhorrent regardless and has nothing to do with the freedom of software. It is, plain and simple, wrong. DSL -Original Message- From: meryl To: slug@slug.org.au Subject: [SLUG] Re: [chat] yet another reason to advocate Linux Date: Thu, 15 Apr 2010 16:40:54 +1000 ... the point of the article was that MS & Apple are using exploitative child labour in sweatshop conditions. It's an interesting article, well worth the read. Meryl -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: [chat] yet another reason to advocate Linux
... the point of the article was that MS & Apple are using exploitative child labour in sweatshop conditions. It's an interesting article, well worth the read. Meryl -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: Time Pedantry (was Re: [SLUG] Which bank doesn't use Linux servers?)
On Thursday 15 April 2010 13:35:13 Adam Kennedy wrote: > And the next thing you know, > incrementing by a day involves half a CPU second because you need to > run a physical model of the orbit of the moon to work out if you are > at a month boundary. If you're trying to deal with that calendar, even that won't work since it is based on the physical sighting of the crescent after the new moon (if it's overcast at sundown, no new month for you). Even absent that you would have to have a latitude and longitude to figure out if the crescent was visible at sundown at the particular location. I once suggested it might be more cost effective to arrange to paint the moon black so that calendar was no longer able to be used. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Best API/abstraction?
I second Perl's DateTime module. It is by far the best time API I've ever seen, if only because it utterly refuses to give you an answer that isn't strictly valid, and throws exceptions if you blink at it wrong. This results in a very rapid learning process where by you are forced to learn how to phrase the question you REALLY want answered instead of just asking it naively and getting garbage-in garbage-out problems later. Once you've adapted to things like always giving it timezones (because there's lots of things it won't answer with floating timezones) and understanding that it's going to answer "How long from 2:30am today until 2:30am tomorrow" with simultaneous answers in days, hours and seconds (all three of which won't divide into each other necessarily) you really appreciate it. I've yet to see anything else that is even close. Adam K On 7 April 2010 15:14, Daniel Pittman wrote: > Jeff Waugh writes: >> >> >>> I for one am glad such pages exist. I wish the inventors of time_t had >>> read it. >> >> So which language / library has a great abstraction for time and date stuff, >> helping you deal with the intricacies of this craziness? > > None of them. Even the good languages have nasty side-bits like a "don't be > broken" switch, and even a perfect language would still have the pain of > dealing with political, not technical, issues like timezone-associated dates. > > Oh, and the fact that date math is *not* simple, since you can't convert > between various durations; a question such as "how many seconds in a week" can > only be answered "it varies..." > > > FWIW, the link I posted earlier was about time handling in Common Lisp, which > gets this less wrong than most platforms ... but that document was written > because the standard was imperfect. > > Perl, meanwhile, has good support in various non-core library modules, but > many of those have things like a "$Class::Date::DST_ADJUST" value to determine > which behaviour you want for math involving DST and/or leap-seconds. > > > As an example of a well-documented set of complications and how they are > handled, the DateTime module does well: > > http://search.cpan.org/~drolsky/DateTime-0.55/lib/DateTime.pm#How_Datetime_Math_is_Done > > After you read through the 250 lines of warnings, complications, caveats, and > examples of how you can have two completely correct, valid, sensible results > that are absolutely in contradiction with each other... > > Heh. > > Time. Boy, does it suck. :) > Daniel > > -- > ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 > ♽ made with 100 percent post-consumer electrons > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: Time Pedantry (was Re: [SLUG] Which bank doesn't use Linux servers?)
Of course, that brings up the issue of WHAT day it is, and the need to cleanly support non-gregorian calendars. And the next thing you know, incrementing by a day involves half a CPU second because you need to run a physical model of the orbit of the moon to work out if you are at a month boundary. Adam K On 1 April 2010 16:11, Peter Hardy wrote: > None of this would be a problem if we'd just switch to decimal time in a > single timezone and call it a day. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Debian Lenny HAL Config
Hello Rodolfo, Replied earlier, but its gone somewhere. I looked at the doco. Thanks for the reference. Did you update it just for me? [Thanks.] I used the doco to add a local rule for accepting guids in the mount command, as configured via gconf. A mount controlled by goconf now accepts a guid where as it did not before (I had already tried to fiddle with gconf). But, the group is still set to root after the mount. gconf mount options for vfat now are: [shortname=mixed,uid=,gid=] In user-options.fdi I have: type="strlist">usefree gid On a related but different topic, how do I force hal to always mount the usb card as me (chris). I am not the only user on the console, I have to play round robin and a game of chance for the card to be mounted under my uid. Thanks and regards, Chris. Rodolfo Martínez wrote: Hi Chris, The "Changing default mount options" section at http://www.linuxfromscratch.org/blfs/view/cvs/general/hal.html may help. -- Rodolfo Martínez On Mon, Apr 12, 2010 at 6:39 AM, Chris Perry wrote: Hello, I have used Debian for over a decade and can work most things out. But I have a problem. I use a usb memory card to take a rsync backup of my most important files every day. This used to work perfectly. I recently upgraded from etch to lenny. After ironing out some wrinkles I am left with one insoluble problem: The usb memory card is always auto mounted with group ownership of root at the mount point. This stops me from refreshing the cards contents. In etch ownership after auomount would be chris:perry This is as expected and worked fine. In lenny ownership after automount is chris:root This is the problem. My primary group is still perry, btw. I have googled and searched far and wide, I cannot find posts that describe adequately how hal and then udev get themselves sorted and apply some action to perform the mount. I cannot work out where the action is defined in the system config. I cannot work anything out, I've not been so stumped in a long time. I have determined the following work-around to use after automount has completed: umount /media/TOSHIBA mkdir /media/TOSHIBA mount -t vfat -o rw,nosuid,nodev,uhelper=hal,shortname=lower,uid=1000,gid=1004 /dev/sdc1 /media/TOSHIBA I am not able to determine the output of mount for the same device in etch. My backup etch partition has passed on. If someone can point me at the right doco, or desribe how this works, I would appreciate it. Thanks and regards, Chris. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
