Gog, why is it you're so determined to delete this?
I'm working on it and its a valid topic.
- because it reads like a blog and its kinda wierd. compare it to the rest of the stuff. how to install this that BAM PHILOSOPHICAL BREAKTHROUGH
Ya know, a lot of the stuff on this wiki is just plain out of date.
Don't you think it would be more productive to try to find stuff that just doesn't even apply to the current arch system and update or delete that.
Take a look at Arch64, there are 3 or 4 different ways of implimenting this and there is no contextual information on how or when these work together or when they are mutually exclusive. For instance, the "Current State of Arch64 Development" which is 2 years old.
A lot of times things are at first done by individuals, then eventually some variation on the theme is included in the standard distribution. A wiki article describes the original work, but it's never updated to indicate that this is all build-in now.
There's a lot of specific information, but much of it is not current, and almost none of it is tied together.
It seems a lot of work could go into making the wiki more organized and relating the various topics to each other.
This would make a resource for arch users new and old.
With all of this lacking in the current documentation, I don't understand the need to be some kind of self expression censor.
this article started when I was investigating posix time and the recently passed leap second.
The fluffy stuff at the beginning is an introduction to the details.
The next bit is a copy and paste from an email exchange with Jamie Zawinski and then some links saved at the bottom so they don't get lost before coming back around to it. The original intent of the article is to be about 3 times the current length.
After being a degreed EE in industry for 26 years it gets pretty fucking boring reading a bunch of acronyme enhanced techno bable in run-on third person sententences with the drilled down lack of context of an autistic plastic pocket protector.
Additionally the "normal" non-weird style lends itself to almost immediate obsolescence because of its lack of context.
I'm not sure what you do with your days, but over here there's a mortgage, a kid with the flu, three projects that need attention for clients, past due taxes, and plenty of other "normal" duties vying for my time. If I spend time writing about time keeping in unix computing, I want it to be fun as well as informative.
I didn't realize the arch community had such strict standards of boringness.
I've been running this distro for 6 years, pretty much every day. I'm not a maintainer, but I am a reasonably knowledgable user. I'd like to spread some of that knowledge to help arch users understand how their whole system fits together. A comprehensive understanding is not reached by each specific detail alone, it requires context and inter-relation.
The wiki should be THE ARCH BOOK. This requires that each article be maintained, not just a bunch of details that are correct in the moment but superfluous 6 months down the road. Otherwise it will always be in a shambles and mostly out of date with no cohesive vision that guides the reader or future contributions.
That's my bit.
Best of luck...
New initscripts and hwclock daemon
With the latest initscripts package, the hardware clock is kept updated differently than how it's explained here (for example it's not in rc.shutdown any longer), I am still trying to understand well, so I cannot update the article by myself. For now I'm marking it as out of date. -- Kynikos 16:09, 3 May 2011 (EDT)
- At the moment I link the bug report that seems to be responsible for this change: FS#13684. -- Kynikos 16:39, 3 May 2011 (EDT)
Note in the About section
Hi there. I just got throught installing arch on a dualboot system. I saw how I can configure all this time-stuff, but didn't get what it is I'm supposed to be doing. (No problem following instructions, but.. what's the current situation, and what's the target?) Found this page, and read it. I only understood clock and time. So I played around (with UTC, changing BIOS clock, windows clock, linux clock, rebooted and looked at how the other clocks reacted). Then it was ovious. Reading throught the about section again I was puzzled why I didn't understand the concept perfectly on the first read, because it's all there, in detail.
So I added this note. I couldn't improve the About section itself, because it's all there already. But it's a lot of text with a lot of clocks (;) . I didn't want to dumb it down, and adding to it doesn't help the beginner, it's just more clocks. So I thought I'll just add a simple version of what's going on, seperate from the detailed information
But I know it's dublicated information, so someone might just delete it for that reason, and this is why i write here. Please don't delete it. It's a little bit of a chicken and egg problem, at least for me. This article needs a very basic explanation of what going on.
- Please sign your edits in talk pages.
- Don't worry, it's going to stay, I've just reworded it a bit and removed the Note template since it can't be considered a note. -- Kynikos 07:08, 15 October 2011 (EDT)
How to set Windows to use UTC
- You know that every time you write the word Win**** in the ArchWiki, god kills a kitten!
- Yeah copy-paste it ;)
- -- Kynikos 05:12, 29 November 2011 (EST)
Time#hwclock daemon says that "[...] the
/etc/rc.d/hwclock daemon uses
hwclock to set the system and hardware clocks on boot [...]" but is that true? By looking at hwclock's source code it does nothing at boot. In fact that should be done by /etc/rc.sysinit as explained at the end of Time#Time standard. Probably somebody with good knowledge of the matter should come and clean things up.
This discussion is also related to Talk:Network Time Protocol daemon#Syncing at boot.
-- Kynikos 11:03, 20 January 2012 (EST)
Hardware clock and system clock
Time#Hardware clock and system clock says that setting the hwclock based on swclock uses the command "hwclock --systohc", but I tested by myself this command and seems that without the UTC parameter ("hwclock --systohc --utc") its sets the hwclock in localtime.
This sounds a bit ambiguous because you can make an inference from what was said on above section ["To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.)"] that the "hwclock --systohc" will do the same.
(Get this info in section "Setting the hardware clock" on this link: Linux Tips - Linux, Clock and Time)
--Gabriel B. Casella 18:13, 11 March 2012 (EDT)