Re: Software requirements
On Wed, 21 Dec 2005, Poul-Henning Kamp wrote: > > I think the difference between you and me as a programmer is that > if you make a mistake, some radio telescope bungles up an observation > or worst case runs against a mechanical end-stop. Or kills somebody. A telescope is as dangerous as any other robotically-controlled multi-ton piece of industrial machinery. Pete.
Re: Software requirements
Feliz Navidad! My gift to all (not least myself) is to omit a reply to Mr. Kamp's latest, except... 3. Realize that the Earth is a lousy clock and go entirely atomic. Or realize the Earth isn't a clock at all, but rather the thing being timed. If you don't care about time-of-day, why mark time at all? Joyeux saut de seconde 2005! Rob
Re: Things to do at about 2005-12-31 23:59:60Z
On Mon, Dec 19, 2005 at 11:31:22PM +, Markus Kuhn wrote: > Surely you are all very busy with last-second shopping for the many > forthcoming leap second parties later this month. > > But what interesting things *are* there to do during a leap second? Tom Van Baak has a bunch of ideas on his page: http://www.leapsecond.com/notes/leap-watch.htm It should be fun. Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Re: Software requirements
In message <[EMAIL PROTECTED]>, Ed Davies writes: >Rob Seaman wrote: >So I'd say there are really three options being debated: > >1. leap seconds. > >2a. leap hours. > >2b. give lip service to leap hours for now but actually be leap > free in practice. Four really, some of us say: 3. Realize that the Earth is a lousy clock and go entirely atomic. But for all practical purposes the difference between 2b and 3 is not something I (need to) care about. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Software requirements
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Dec 21, 2005, at 1:33 PM, Poul-Henning Kamp wrote: > >> You can't separate software from "the real world" any more and >> therefore "software must be responsive to real world issues" is >> about as meaningless as saying "timber must respect the US >> constitution". > >And yet roller coasters must acknowledge gravity, and the space >station control software, the vacuum of space. That is utterly irrelevant: Gravity and vacuum of space are not human conventions they are laws of nature. Leap seconds and indeed any enumeration of time is merely a human convention, and one which have changed many times over history and between cultures. >> As complexity increases, the situation only looks more and more bleak. > >You're a real fun guy, you know it? Complexity is where the fun is. I fully agree, and as long as I only endangered my own close proximity with my coding I used to take the traditional view on software quality: "If the holes go all the way through the card, it's high quality". :-) Unfortunately, I find myself, despite my best efforts, being a victim to the still largely unproven older-wiser connection these days. >Blindly pursuing the deprecation of leap seconds doesn't avoid >liability, it creates it. You seem to think that it will result in a net increase, I think it will result in a net decrease. A better less loaded wording would therefor be "shifts liability". >Arguing that programmers are too ignorant >or careless to correctly account for real world constraints is not a >winning selling point for software solutions. I'm as ashamed as the next guy at how lousy programming is in general, but I still don't see any major willingness anywhere to pay the higher price of quality programming. So while the argument may not sound like a winning selling point for you, I suspect that the vast majority of relevant decision makers will merely ask "Which option costs more money ?" Some of them might after a brief pause ask "... and human lives ?" It would be a nice world where we could all take TF.460, smack our customers, politicians, project leaders etc. on their pointy haired heads and say: "Give me the time and money to do this programming properly!" and have them magically obey the holy writing. It ain't this world though. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Software requirements
On Dec 21, 2005, at 1:33 PM, Poul-Henning Kamp wrote: I think the difference between you and me as a programmer is that if you make a mistake, some radio telescope bungles up an observation or worst case runs against a mechanical end-stop. If I make a mistake in FreeBSD millions of machines may bungle up things I have not even dreamt about them doing. Sucks to be you. My daughter had an assignment to find logical fallacies in newspaper articles and letters to the editor. Reminded me of my undergrad course in logic. Perhaps you took such a course, too. You might also find like I did that you can benefit from a refresher: http:// www.fallacyfiles.org. Your postings often resort to variations of ad hominem attacks. Your assertions in various instances may or may not be correct, but your arguments are often fallacious and provide no benefit to your own position, let alone to the larger discourse. Observatories and other scientific establishments are actually rather risky places. Those risks are often familiar (hearts attacks on remote mountaintops, car accidents on icy switchbacks) but may also be rather terrifyingly strange: http://en.wikipedia.org/wiki/ Louis_Slotin You can't separate software from "the real world" any more and therefore "software must be responsive to real world issues" is about as meaningless as saying "timber must respect the US constitution". And yet roller coasters must acknowledge gravity, and the space station control software, the vacuum of space. The US Constitution and Federal Code (the software) must rather be responsive to the realities of forest growth. We can pass laws allowing the clear cutting of timber, but growing a new forest depends on facts outside of the legal framework. It can be asserted that nobody (important) cares about leap seconds - but that doesn't mean it's true. Saying "timber must respect the US constitution" is actually more closely akin to saying "Earth orientation (UTC) must respect the ITU". It used to be that a timeout for the light in a staircase was a small rubber gadget that slowly let air out, these days it is a microcontroller programmed by some random bloke who can't even pronounce your name. Rather the deployed systems include examples of each of these. Many staircases don't have timeout devices. Many don't have lighting. Many buildings don't have staircases where they should. There are more fundamental issues than outsourcing, and a mastery of English is not required to program microcode. As complexity increases, the situation only looks more and more bleak. You're a real fun guy, you know it? Complexity is where the fun is. A couple of weeks ago to unmanned trolley busses in Holland collided despite all the testing of the controlling systems. What precisely is the useful cargo of an unmanned trolley? Perhaps you meant "unpiloted"? Would love to see one of our perennial local light rail proposals adopted. I guarantee a Teamster will be at the controls. Some real world constraints are even less negotiable than the laws of physics. PGN's RISKS digests has been full of tales of software that is "responsive to the real world" and I can only say I am amazed that no more people have been killed by computers so far. Oh please! The enumerated risks are much more frequently (like always) the result of being unresponsive, or "improperly responsive", to the real world. Planes fall from the sky because of gravity. They stay up because of aerodynamics. Their rapid descent may only be triggered by FreeBSD, not caused by it. You're not the only one who reads RISKS: http://catless.ncl.ac.uk/Risks/20.71.html#subj14.1 Once more with feeling. There are risks associated with leap seconds. There are risks associated with not issuing leap seconds. Software (whether OF the real world or IN the real world) must be responsive to both classes of risk if the programmers are to avoid moral and legal responsibility for any harm that results. Blindly pursuing the deprecation of leap seconds doesn't avoid liability, it creates it. Arguing that programmers are too ignorant or careless to correctly account for real world constraints is not a winning selling point for software solutions. Rob Seaman National Optical Astronomy Observatory
Re: Software requirements
Rob Seaman wrote: ... Two options are currently being debated - leap seconds or leap hours. ... Yes - but I thought there was the idea floating around that in practice the powers that be would chicken out before actually implementing the leap hour. Instead they'd leave international civil time (or whatever you want to call it) leap free and instead muck with the offsets between that and local civil times (as is currently done for daylight saving). My understanding is that the US proposal for leap hours is a bit of bureaucratic subterfuge because UTC is supposed to be related to UT. They'd have to get changes to higher level documents or something to cancel that. So I'd say there are really three options being debated: 1. leap seconds. 2a. leap hours. 2b. give lip service to leap hours for now but actually be leap free in practice. The choice between 2a and 2b can be deferred for a couple of centuries. Ed.
Leap seconds past and future.
I have an audio tape that I recorded of a prior leap second from the BBC World Service radio, and they do have seven pips. It's a nice combination of the old and new, starting with the Westminster Chimes, the pips, and finally the strike of Big Ben. -- I've started "watching" the upcoming leap second by manually recording the time displayed on a digital clock at 08:00:00 Eastern Standard time each morning since December 1st. The clock is a Heathkit digital clock that I made in 1972 that counts the 60 Hz electric power frequency and I'm listening to WWV for the real time. The results are all over the place and I think the leap second will be lost in the clutter. I'll post results at the end of January. -- I've also arranged to have a friend videotape the display on two of my clocks during the leap second. I have a Ultralink WWVB clock and a Traconix WWV clock. Dennis O'Keefe New Paltz, New York, United States
Re: Things to do at about 2005-12-31 23:59:60Z
Yes, the BBC will broadcast seven pips instead of the usual six. However, I leave it to someone else to verify this by direct observation, because my return flight from the western United States lands in London at 11 a.m. GMT on 31 December, and the combination of travel fatigue and the need to adjust my body clock by eight time zones means that I am very unlikely to be conscious at the critical moment :-) David Harper -- Dr David Harper Wellcome Trust Sanger Institute, Hinxton, Cambridge CB10 1SA, England Tel: 01223 834244 Fax: 494919 http://www.sanger.ac.uk/Users/adh/
Re: Things to do at about 2005-12-31 23:59:60Z
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >But what interesting things *are* there to do during a leap second? I'm going to record all the bits and waves I can doing the leap second, and I have asked the GNUradio, NTP and time-nuts communities to please help me do so. With a little luck the result will be a freely available repository of test data so people can test and fix the leap-second handling bugs in their software before the next one. All of it, however will be running on automatic because I'm in no shape to control a UNIX prompt at 1AM new years night. >If you have a counter connected to the power grid, at least in most of >Europe (i.e., the UCTE 50 Hz network), you should see that -- thanks to >the leap second -- the frequency will during the following day be set >slightly lower, to ensure that European electricity consumers pay back >the free 50 cycles they got during the leap second. (But it may take a >few days of averaging until this long-term phase shift by 50 cycles >actually becomes clearly visible in the general phase/frequency noise of >the power grid.) I think this isn't the case anymore. After the market got deregulated I don't think anybody is trying very hard to keep the long term average at 50 Hz anymore, and at least here in Denmark (NorthPool side) we're often as much as 15 seconds behind during winter. >It might be fun to compile a comprehensive documentary here on how the >leap second is implemented in practice today ... I'm a few hours ahead of you, and welcome you and anybody else to join me: Any and all records will be collected and made available. Observations of microsoft computers and the interactions between clients and servers would be a very important subject in addition to the many other worthy ideas you mention. Poul-Henning PS: I'm trying to persuade the local watch-shop to let me put a video camera in their shop and record a wall full of assorted clocks, some radio, some not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Software requirements
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Dec 21, 2005, at 3:06 AM, Poul-Henning Kamp wrote: > >> It must be wonderful to live in a world where software can just be >> ignored or marginalized at whim, I really envy you. > >Sarcasm, right? yes, deeply. >Software IS a marginal activity - I say this as a programmer. There >is no point to software that doesn't address the external needs of >some class of users. I think the difference between you and me as a programmer is that if you make a mistake, some radio telescope bungles up an observation or worst case runs against a mechanical end-stop. If I make a mistake in FreeBSD millions of machines may bungle up things I have not even dreamt about them doing. For Windows the problem is two orders of magnitude higher. There is programming and there is programming. BTW: Has anybody actually heard Microsoft come out and say "Our operating systems will do the right thing ?" I havn't... >Time standards represent just one set of >constraints placed on a wide range of software. No one is suggesting >software requirements be ignored, but those requirements must be >responsive to real world issues, and software professionals >themselves (like astronomers) are only one community that must inform >the standards process. Ahh, but there we have the marginalization again: "software must be responsive to real world issues". Software very much an *integrated part* of the real world, and does in fact implements far more of the higher level behavioural systems in hour hi-tech society than any other technology. You can't separate software from "the real world" any more and therefore "software must be responsive to real world issues" is about as meaningless as saying "timber must respect the US constitution". This should not be surprising because software has over the last 10 years become the dominant way to implement control systems and behavioural decisions in technology. It used to be that a timeout for the light in a staircase was a small rubber gadget that slowly let air out, these days it is a microcontroller programmed by some random bloke who can't even pronounce your name. As complexity increases, the situation only looks more and more bleak. A couple of weeks ago to unmanned trolley busses in Holland collided despite all the testing of the controlling systems. The press quoute was "We have no idea why..." PGN's RISKS digests has been full of tales of software that is "responsive to the real world" and I can only say I am amazed that no more people have been killed by computers so far. Much of the trouble with software is that it _is_ responsive to the real world issues, unfortunately it tends to be responsive to the real world issues in the same way the US auto industry is responsive to global warming: "Hey, not my problem!" Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Things to do at about 2005-12-31 23:59:60Z
On Mon, Dec 19, 2005 at 11:31:22PM +, Markus Kuhn wrote: > > http://washingtontimes.com/upi/20050707-090936-2878r.htm It would take of course, people as pedantic as those of us who have an interest in a leap second to point out that the article is wrong in its claim that " This year, 2005, will be one second longer than any year since 1998.", since 2000 and 2004 were leap years and were longer than 2005 by 86,399 seconds. :-) -- Randy Kaelber[EMAIL PROTECTED] Scientific Software Engineer Mars Space Flight Facility, Department of Geological Sciences Arizona State University, Tempe, Arizona, USA
Software requirements
On Dec 21, 2005, at 3:06 AM, Poul-Henning Kamp wrote: It must be wonderful to live in a world where software can just be ignored or marginalized at whim, I really envy you. Sarcasm, right? Software IS a marginal activity - I say this as a programmer. There is no point to software that doesn't address the external needs of some class of users. Time standards represent just one set of constraints placed on a wide range of software. No one is suggesting software requirements be ignored, but those requirements must be responsive to real world issues, and software professionals themselves (like astronomers) are only one community that must inform the standards process. The world rotates. Its rotation is slowing. I won't belabor the implications, but these are facts of nature that must be accommodated in some fashion. Two options are currently being debated - leap seconds or leap hours. The former establishes a relatively rapid cadence of events with a small enough amplitude to allow each instance to be ignored for many purposes (software included). The latter permits a slow cadence (for the near term) that permits the existence of the requirement to be ignored for long periods of time for many, but not all, purposes. The amplitude, however, is much larger and many more users (and their software) would have to be made DUT1 aware. When the inevitable leap occurs, its larger amplitude will represent a larger challenge for programmers and civilians alike. The rare occurrence of events makes mistakes more likely. Everybody on this mailing list obviously welcomes the opportunity to discuss which option is better. Or perhaps we can establish a consensus around some other proposal. This is more likely to happen if the proposal is the product of all the folks on the list, not just the lurkers. In any event, software requirements will better be met by designing, implementing, documenting and maintaining a coherent set of interfaces for transporting time signals of all types. It's easier to focus on technical requirements when politics isn't allowed to dominate the standards process. Rob Seaman National Optical Astronomy Observatory
The only solid argument for leapseconds :-)
http://www.comics.com/comics/franknernest/index.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Schreiver AFB warns about leapsec
In message <[EMAIL PROTECTED]>, Francois Meyer writes: >On Tue, 20 Dec 2005, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED] >on.fr>, Francois Meyer writes >> : >> >> >I second this too, 23:59:59 is the worst time to >> >insert a leap second, since failing to implement it >> >leaves you with the wrong day (month and possibly >> >year) at the very second it occurs. >> >> That is probably one of the strongest arguments for retaining that >> moment of insertion: That way computer bugs are more likely to >> be noticed. > >UTC is not a debugging tool, it is an international >standard. Software is an an issue but I think it >cannot justify in itself that leap second impact >should be as large as possible. It must be wonderful to live in a world where software can just be ignored or marginalized at whim, I really envy you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Schreiver AFB warns about leapsec
On Tue, 20 Dec 2005, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Francois Meyer writes > : > > >I second this too, 23:59:59 is the worst time to > >insert a leap second, since failing to implement it > >leaves you with the wrong day (month and possibly > >year) at the very second it occurs. > > That is probably one of the strongest arguments for retaining that > moment of insertion: That way computer bugs are more likely to > be noticed. UTC is not a debugging tool, it is an international standard. Software is an an issue but I think it cannot justify in itself that leap second impact should be as large as possible. -- Francois Meyer Tel : (+33) 3 81 66 69 27 Fax : 3 81 66 69 44 Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE Université de Franche-Comté ** CNRS UMR 6091 *
Re: Schreiver AFB warns about leapsec
- Original Message - From: "Tom Van Baak" <[EMAIL PROTECTED]> To: Sent: Tuesday, December 20, 2005 5:09 PM Subject: Re: [LEAPSECS] Schreiver AFB warns about leapsec > > > While you're at it let's change when leaps occur; not > > > just at 23:59:59 > > > ... > > I second this too, 23:59:59 is the worst time to > > insert a leap second, since failing to implement it > > leaves you with the wrong day (month and possibly > > year) at the very second it occurs. > > Given the way Olympics are promoted these days, > as well as stadium naming rights, billboards, web > advertising, and google adwords, perhaps the ITU > can get commercial sponsorship for future scheduled > leap second events. Commercial interests have long > since claimed trademarks on otherwise free letters, > words, and symbols. So how about time itself? > > The income could be applied as grants to those trying > to correctly implement and debug the growing global > list of time interconnected technologies. And no small > percent to astronomers so they have real-time precision > access to UT1. Everyone is happy. (If this happens I will > deny ever having suggested it). > > "Coca-Cola is the official sponsor of the December 2005 > leap second. The one second pause that refreshes." > > "Panasonic is the official sponsor of the June 2007 > leap second. Just slightly ahead of Earth time." > > /tvb "WWV...You give us 22 minutes, we'll give you 21 minutes and 60 seconds." Brian
