Many binary computers will die in 2022

[skybuck2000]

How do I know,

My kitchen lamp died on 2-1-2022 lol.

It's a message from some external universe.

Let's see if it becomes true ! =D

Bye,
Skybuck.

[MitchAlsup]

On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
> How do I know,
>
> My kitchen lamp died on 2-1-2022 lol.
<

Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.

[Stefan Monnier]

MitchAlsup [2022-01-03 09:21:53] wrote:
> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>> How do I know,
>> My kitchen lamp died on 2-1-2022 lol.
> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.

I think he used the saner little endian notation.
Noone can always be wrong.


Stefan

[David Brown]

On 03/01/2022 18:21, MitchAlsup wrote:
> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>> How do I know,
>>
>> My kitchen lamp died on 2-1-2022 lol.
> <
> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.

Dates in most of the world are ordered more logically than the USA -
either day, month year, or year, month, day.

Mind you, the PDP-endian US format gave us the international holidays of
Pi Day and Star Wars Day, so it has /some/ uses!

:-)

[Guillaume]

Well, yes, I've always found US dates odd. I'm not a native speaker, so
I don't really know all the history. But in English, dates can be
written either "January 2" or "the 2nd of January". The number-only form
matches the first. I suppose this is because it's the more compact way
of expressing it, and americans tend to prefer compact and efficient.

[David Brown]

In Britain, "January the second" used to be a common verbal form for
dates, and is still used occasionally, especially amongst older people.
"2nd January" (written long form), or "The second of January" (spoken)
are much more common. When writing with a year, day-month-year order is
almost invariably used (except for some contexts in which ISO formats
such as 2022-01-02 are appropriate or more convenient).

Americans are more conservative, and resist change. The UK moved on to
the more logical and consistent format in the mid 20th century, but the
USA stayed behind (just like for measurement systems and 24 hour clocks.
Americans like to point out Fahrenheit, pounds and inches got them to
the moon - fair enough, but perhaps with a sane measurement system
they'd be on Mars by now).

There is nothing "compact" about the American way - it's just jumbled
and has no advantage compared to an consistent order. (Just as it's
okay to like little-endian, and to like big-endian, but PDP mixed-endian
is just awkward.)

[JimBrakefield]

I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
Also used on handwritten note pages
PDF files suffixed by author and year _nnn...yyyy
Is there a windows utility that will sort directories using the last letters and digits in the file name?

American, and have become more and more enamored of organizing stuff by date

[Guillaume]

Le 04/01/2022 à 01:14, JimBrakefield a écrit :
> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
> Also used on handwritten note pages
> PDF files suffixed by author and year _nnn...yyyy
> Is there a windows utility that will sort directories using the last letters and digits in the file name?

There may be. I don't know of one. Maybe have a look at Total Commander?

Otherwise, one thing you could do is to se the modification date of each
file to the date that is associated with it in the filename, using Power
Shell (see the part "To set the specific timestamps..."
https://www.shellhacks.com/windows-touch-command-equivalent/

And, I'm sure a small script could automate this. Not very proficient
with Powershell, but it should be straightforward.

After that, you can just sort the files by date in the file manager.

[BGB]

I have typically used "YYYY-MM-DD", as it seemed obvious enough.
Annoyingly, I have found, other people IRL are hopelessly confused by
any date not in the 'MM/DD/YY' or 'MM/DD/YYYY' formats.

A lot of my documentation files have the origin date as a name prefix,
may eventually get updated, but usually reflects when the file was first
created more than when it was last edited (though, usually the
filesystem keeps note of this one).



But, oh well. Due to "ongoing can't seem to get anyone to consider
hiring me to do anything" issues (*), have started working on another 3D
engine. I suspect there is at least slightly higher probability of being
able to make something "marketable" as an indie game than with the BJX2
core. I found this project interesting, but there doesn't seem to be any
real potential way to get any sort of income from this (well, short of
GitHub Sponsors or similar, but this seems unlikely).

*: Like one can apply to lots of jobs, but invariably either hear
nothing, or get the occasional automated "screw off" email as a response
(whole life thus far is basically this).


I could have resumed working on my old 3D engine, but there was enough
stuff I wanted to do differently that it seemed better to pull a reset
(it was being based off of BtMini). Funny enough is that right now I
have an engine doing Minecraft style terrain but currently using around
40-60MB of RAM...

Though, the bigger RAM waster would likely be if I switched back to
per-chunk vertex arrays. At the moment, the renderer is based around the
use of ray-casts (cast a ray, and if it hits a block we haven't hit yet,
add it to the list; then draw all the blocks that were hit).

Drawback is that ray casting doesn't work as well with larger draw
distances. PC can afford a higher ray density and larger trace-distance
limit, but this only goes so far.

Some point may also need to switch it over to using the GPU for
rendering, at the moment I am using my software GL rasterizer, ...

Current idea otherwise is (besides the blocky terrain), trying to rip
ideas off of a few other (fairly popular) games (namely Undertale and
Stardew Valley). Well, and ye olde "retro aesthetic" (make the textures
32x32, use 32x64 pixel character sprites, use 8kHz ADPCM for sound
effects, ...).

As with my last effort, I am (again) going with sprite-based graphics
and atlas textures. Difference is mostly that I have (somewhat) reduced
the resolution. It is likely that "wander around and interact with NPCs"
will remain a focus.

Lacking much better, also just sort of going with an XML based notation
for the dialog and menu systems (and a "binary serialized XML" format
for the entity graph; ...). The last engine had tried to use a dialog
system built around building object graphs in code, but this was kinda
painful and didn't scale very well (and my ideas for a wiki-notation
format fizzled; but XML notation is at least competent at blobs of text
interspersed together with block structuring).


Though, even if it somehow "doesn't suck", the likelihood of "success"
is pretty low (given the huge number of indie games around, most of
which don't amount to much; and "no one cares", which is why I am here
to begin with).

Similar with writing Sci-Fi, never sold enough E-Books to actually make
anything from it (so, sadly, one needs some level of popularity as a
starting point).

Or, basically, all the reasons I am here to begin with.

...

[Stephen Fuld]

See the Lifestreams project at

http://cs-www.cs.yale.edu/homes/freeman/lifestreams.html

From that page


> Lifestreams is built on a simple storage metaphor --- a time-ordered stream of documents combined with several powerful operators --- that replaces many conventional computer constructs (such as named files, directories, and explicit storage) and in the process provides a unified framework that subsumes many separate desktop applications to accomplish and handle personal communication, scheduling, and search and retrieval tasks.


--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[Thomas Koenig]

BGB <cr8...@gmail.com> schrieb:

> On 1/3/2022 6:14 PM, JimBrakefield wrote:
>> On Monday, January 3, 2022 at 12:33:26 PM UTC-6, Guillaume wrote:
>>> Le 03/01/2022 à 19:16, David Brown a écrit :
>>>> On 03/01/2022 18:21, MitchAlsup wrote:
>>>>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>>>>> How do I know,
>>>>>>
>>>>>> My kitchen lamp died on 2-1-2022 lol.
>>>>> <
>>>>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>>>>
>>>> Dates in most of the world are ordered more logically than the USA -
>>>> either day, month year, or year, month, day.
>>>>
>>>> Mind you, the PDP-endian US format gave us the international holidays of
>>>> Pi Day and Star Wars Day, so it has /some/ uses!
>>> Well, yes, I've always found US dates odd. I'm not a native speaker, so
>>> I don't really know all the history. But in English, dates can be
>>> written either "January 2" or "the 2nd of January". The number-only form
>>> matches the first. I suppose this is because it's the more compact way
>>> of expressing it, and americans tend to prefer compact and efficient.
>>
>> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
>> Also used on handwritten note pages
>> PDF files suffixed by author and year _nnn...yyyy
>> Is there a windows utility that will sort directories using the last letters and digits in the file name?
>>
>> American, and have become more and more enamored of organizing stuff by date
>
>
> I have typically used "YYYY-MM-DD", as it seemed obvious enough.

This is pretty much standard in companies here, you will find
many documents with file names starting with the date in this format.

This is also ISO 8601, I think.

[Joe Pfeiffer]

Thomas Koenig <tko...@netcologne.de> writes:

> BGB <cr8...@gmail.com> schrieb:

>>
>> I have typically used "YYYY-MM-DD", as it seemed obvious enough.
>
> This is pretty much standard in companies here, you will find
> many documents with file names starting with the date in this format.

This is its compelling advantage: when you do a 'ls', it collates by
date.

> This is also ISO 8601, I think.

Yet another reason to use it.

[BGB]

This is a partial reason I do this.

Keeps tract of when I write things, and allows "sort by name" to
function as "sort by date written".

[John Dallman]

In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no (David

Brown) wrote:

> Mind you, the PDP-endian US format gave us the international
> holidays of Pi Day and Star Wars Day, so it has /some/ uses!

Keeping the minutes for a weekly 'phone meeting between Brits and
Americans, with a scattering of other nationalities, I found it useful to
adopt the date format used by the US DoD, and VMS: today is 06-JAN-2022.
It isn't anyone's native format, but everyone understands it.

John

[MitchAlsup]

This brings to mind that one can spell the name of the month (abbreviated)
and use any format without any reader error.
<
1-jan-1989
1-1981-jan
jan-1-1989
jan-1981-1
1981-1-jan
1981-jan-1
<
This solves the problem only in the places of the world using the Juliean Callendar, though....
>
> John

[Terje Mathisen]

Joe Pfeiffer wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
>
>> BGB <cr8...@gmail.com> schrieb:
>>>
>>> I have typically used "YYYY-MM-DD", as it seemed obvious enough.
>>
>> This is pretty much standard in companies here, you will find
>> many documents with file names starting with the date in this format.
>
> This is its compelling advantage: when you do a 'ls', it collates by
> date.

I use the same setup, with subdirs named using ISO datestamps, or in the
case of areas of interest, I'll do something like 2021_o for all the
orienteering-related stuff in 2021.

Instead of overwriting the big binary files which contains my
orienteering maps in OCAD format, I always save them with the map name
plus ISO data: Hvaler_2021-09-18.ocd.

This way I know I have a good previous copy if I discover a stupid
error, or if the file save process should crash (which has happened).

>
>> This is also ISO 8601, I think.
>
> Yet another reason to use it.
>

I switched to using ISO dates everywhere possible almost 40 years ago.
Back in Hydro we actually had two corporate standards: Norwegian
day/month/year and ISO YYYY-MM-DD. I was pretty much the only one who
actually used ISO, but I could at least point at the standards document
when people complained to me about my usage. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Terje Mathisen]

And some form of ascii alphabet, i.e. they must be capable of reading
'jan/JAN' and understand it to mean "January in the Gregorian calendar".

Pure ISO numbers 2022-01-06 are even more universal.

[Michael Barry]

I didn't actually check, but I'm almost certain that an unsigned 128-bit integer can comfortably hold the age of our current era of a starry universe in nanoseconds, and that's pretty darned universal.

[Terje Mathisen]

You need to measure in Planck time units, about 1e-43 seconds, needing
~150 bits/second, so I suggest 256-bit unsigned for true universality.

[Thomas Koenig]

Michael Barry <barry...@yahoo.com> schrieb:

So where do you put t=0?

[David Brown]

On 07/01/2022 11:39, Thomas Koenig wrote:
> Michael Barry <barry...@yahoo.com> schrieb:

>> I didn't actually check, but I'm almost certain that an unsigned
>> 128-bit integer can comfortably hold the age of our current era of a
>> starry universe in nanoseconds, and that's pretty darned universal.
>
> So where do you put t=0?
>

01.01.1970, for backwards compatibility. (I think that's how timestamps
on ext4 are done.)

[skybuck2000]

Don't worry guys !

Normally I always write dates with the month name in it as:

2 january 2022 !

Just not this one time because I kinda looks funny.

Bye, Bye,
Skybuck ! =D

[skybuck2000]

BINGO:

https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970

https://tech.slashdot.org/story/22/01/06/2225219/honda-clocks-are-stuck-20-years-in-the-past-and-there-isnt-a-fix

ONE COULD NOW ARGUE THAT MY PREDICTION HAS BECOME TRUE.

NOT ONLY THAT BUT IN A SPECTACULAR WAY.

JUST LIKE MY ORIGINAL HYPOTHESIS, WHICH WAS FOR THOSE THAT MISSED IT:

EXTERNALS COMMUNICATING WITH US THROUGH TIME/CLOCKS.

AND OH BOY HAVE THEY COMMUNICATED CLEARLY TO THIS POSTING OF MINE HAHAHAHAHAHA

CLOCKS OF HANDAS NOW STUCK ! LOLOLOLOLOL.

BYE,
SKYBUCK =D WOOOOOEEEEHOOEEEEEEEEE ! =D

[John Levine]

It appears that Thomas Koenig <tko...@netcologne.de> said:
>> I didn't actually check, but I'm almost certain that an unsigned
>> 128-bit integer can comfortably hold the age of our current era of a
>> starry universe in nanoseconds, and that's pretty darned universal.
>
>So where do you put t=0?

October 23, 4004 BC, of course.

https://blogs.scientificamerican.com/history-of-geology/october-23-4004-bc-happy-birthday-earth/

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Ivan Godard]

On 1/7/2022 10:18 AM, John Levine wrote:
> It appears that Thomas Koenig <tko...@netcologne.de> said:
>>> I didn't actually check, but I'm almost certain that an unsigned
>>> 128-bit integer can comfortably hold the age of our current era of a
>>> starry universe in nanoseconds, and that's pretty darned universal.
>>
>> So where do you put t=0?

At zero, of course.

[MitchAlsup]

Creation of Earth zero or Big Bang zero ?

[Thomas Koenig]

Ivan Godard <iv...@millcomputing.com> schrieb:

Since it is unsigned, it almost _has_ to be the big bang.

If it's seconds, the thornier question is - which reference frame?
Time dilation due to gravitational effect can certainly play a role
which makes this inaccurate...

[Thomas Koenig]

David Brown <david...@hesbynett.no> schrieb:

An unsigned quantity was specified, so no time existed before that,
obviously.

[Ivan Godard]

The trouble with recursive jokes is that they give people stack overflow.

[Ivan Godard]

There are cosmological models in which there was a time before the (most
recent) Big Bang, so that cannot be used as a zero point.
But this is a universal timescale, supplanting any mundane scale, so the
zero of the scale is necessarily Zero.

It's the same as the child's question "Who made God?", but with time
substituted. And as with most theology, can be seen as a recursive joke.

Sometimes, anyway; parse that as you will.

[MitchAlsup]

On Friday, January 7, 2022 at 4:42:32 PM UTC-6, Ivan Godard wrote:
> On 1/7/2022 1:16 PM, Thomas Koenig wrote:
> > Ivan Godard <iv...@millcomputing.com> schrieb:
> >> On 1/7/2022 10:18 AM, John Levine wrote:
> >>> It appears that Thomas Koenig <tko...@netcologne.de> said:
> >>>>> I didn't actually check, but I'm almost certain that an unsigned
> >>>>> 128-bit integer can comfortably hold the age of our current era of a
> >>>>> starry universe in nanoseconds, and that's pretty darned universal.
> >>>>
> >>>> So where do you put t=0?
> >>
> >> At zero, of course.
> >
> > Since it is unsigned, it almost _has_ to be the big bang.
> >
> > If it's seconds, the thornier question is - which reference frame?
> > Time dilation due to gravitational effect can certainly play a role
> > which makes this inaccurate...
<
> There are cosmological models in which there was a time before the (most
> recent) Big Bang, so that cannot be used as a zero point.
<

Yes, but most of these require that time have an imaginary component.
The most reasonable and the model with the most scientific support,
is the one which denotes time beginning at the instant of the big bang
(or within 10^-32 seconds after the BB).

<
> But this is a universal timescale, supplanting any mundane scale, so the
> zero of the scale is necessarily Zero.
>
> It's the same as the child's question "Who made God?", but with time
> substituted. And as with most theology, can be seen as a recursive joke.
<

"can be seen" ?????

[Michael Barry]

On Friday, January 7, 2022 at 10:18:08 AM UTC-8, John Levine wrote:
> It appears that Thomas Koenig <tko...@netcologne.de> said:
> >> I didn't actually check, but I'm almost certain that an unsigned
> >> 128-bit integer can comfortably hold the age of our current era of a
> >> starry universe in nanoseconds, and that's pretty darned universal.

Please don't blame Thomas for my doofy remark.
I visit here often, but rarely post. I don't quite remember why I felt the
need to offer my $0.02 here ... a cosmic ray must have temporarily
flipped my idiot bit.

Mike B.

[Öö Tiib]

But it was funny. And also likely true.
Universe is estimated to be about 4.35e+26 nanoseconds old.
Meanwhile 2^89 is about 6.19e+26.
So it looks like there are plenty of bits to go to reach 128.