- WLUG - wlug.mailman3.com

Re: Reminder! Virtual Meeting Tonight!! 7PM via Jitsi!

by Jon "maddog" Hall

Daryll who? >On April 9, 2010 McBride purchased the SCO Mobility intellectual property from The SCO Group for $100,000. Imagine paying 100,000 USD in 2010 for something that was proven to be worth nothing. Even the name "SCO" is so tarnished after what McBride and his cohorts did that it is worth nothing. On a related note, I made contact with Doug Michels, one of the founders of the original Santa Cruz Operations. Doug is a good guy and I worked with him for years during the heady days of the "Common Desktop Environment". In 1997 Doug was on the board of Uniforum and insisted that Linus Torvalds get a lifetime achievement award at the tender age of 28. md On Thu, Feb 11, 2021 at 12:50 PM Tim Keller via WLUG <wlug(a)lists.wlug.org> wrote: > Hey Gang, > > We've got a meeting tonight at 7PM! > > Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA > > Topic: I think the Itanium thing got beat to death, but we can still talk > about it. > Apparently there's still a pa-risc port of linux kicking around? Now I > want to run it as a VM! > > Daryl McBride (SCO asshole) just fired for Chapter 13 so we can laugh at > his expense. > > I'm sure there'll be some 3d printer talk, some Pi PICO chatter, plus > whatever else. > > Later, > Tim. > > -- > I am leery of the allegiances of any politician who refers to their > constituents as "consumers". > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/HYKKY… >

Feb. 19, 2021

Reminder! Virtual Meeting Tonight!! 7PM via Jitsi!

by Tim Keller

Hey Gang, We've got a meeting tonight at 7PM! Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA Topic: I think the Itanium thing got beat to death, but we can still talk about it. Apparently there's still a pa-risc port of linux kicking around? Now I want to run it as a VM! Daryl McBride (SCO asshole) just fired for Chapter 13 so we can laugh at his expense. I'm sure there'll be some 3d printer talk, some Pi PICO chatter, plus whatever else. Later, Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Keith Wright

"Robert N. Evans via WLUG" <wlug(a)lists.wlug.org> writes: > That is not what I see when I query one of the major name servers. > I would guess your server is configured differently... Yes, know it's configured differently. On purpose. I have configured it _not_ to waste time answering stupid questions from random bots. If you want to know the address of isc.org, ask a major name server. My server is for answering questions about _my_ names. It needs to answer queries about keithdiane.us and free-comp-shop.com, for which it is authoritative, which means the major name servers get their info about those names from _here_. I would like to configure it to totally ignore such stupid requests, instead it seems to be answering with the best data it has in its cache. That turns out to be the most verbose yet useless information imaginable---a list of all the root name servers on the internet! -- Keith PS: Don't use my list. It's probably obsolete.

Feb. 11, 2021

WLUG Meeting Feb 11th 2021! Topic: Good question!

by Chuck Anderson

Correct, Keith's server is not configured to current best security practices. His server has what is called "upward referrals" turned on. https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful I believe what you want at a minimum is: additional-from-cache no; Also, it sounds like you are using your DNS server for two functions: caching for internal clients, and authoritative for your domain name(s). If so you probably should isolate both functions: "If your nameserver is both authoritative and caching, you really should separate the two functions. Caching nameservers are susceptible to poisoning and other types of attacks. You don't necessarily need separate hardware for each. You might need to use separate IP addresses, or possibly configure the authoritative nameserver to use an external address while the caching nameserver uses an internal address." See also: https://kb.isc.org/docs/bind-best-practices-authoritative and: https://kb.isc.org/docs/bind-best-practices-recursive On Thu, Feb 11, 2021 at 10:08:21AM -0500, Robert N. Evans via WLUG wrote: > That is not what I see when I query one of the major name servers. I would guess your server is configured differently... > > rne@P5:~$ dig @1.1.1.1 isc.org > > ; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 isc.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31866 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;isc.org. IN A > > ;; ANSWER SECTION: > isc.org. 9 IN A 149.20.1.66 > > ;; Query time: 24 msec > ;; SERVER: 1.1.1.1#53(1.1.1.1) > ;; WHEN: Thu Feb 11 10:03:30 EST 2021 > ;; MSG SIZE rcvd: 52 > > > -BE > > -----Original Message----- > >From: Keith Wright via WLUG <wlug(a)lists.wlug.org> > >Sent: Feb 11, 2021 1:04 AM > >To: Worcester Linux Users' Group General Discussion <wlug(a)lists.wlug.org> > >Cc: wlug(a)lists.wlug.org, Andre.Lehovich(a)gmx.com, Keith Wright <kwright(a)keithdiane.us> > >Subject: [WLUG] Re: WLUG Meeting Feb 11th 2021! Topic: Good question! > > > >Andre Lehovich via WLUG <wlug(a)lists.wlug.org> writes: > > > >>> dig @66.92.74.188 isc.org > >> > >> Here you go, hope it's useful... > > > >Thank you. That's a lot of information. > > > >> quetzal:~ al$ dig @66.92.74.188 isc.org > >> > >> ; <<>> DiG 9.10.6 <<>> @66.92.74.188 isc.org > >> ; (1 server found) > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11995 > >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 > >> ;; WARNING: recursion requested but not available > > ^^^^^^^^^ ^^^^^^^^^ ^^^ ^^^ ^^^^^^^^^ > >That looks good. > >I don't want to be doing recursion for you (nothing personal). > > > >But where did all the rest of that come from? > >I've never seen anything like that! > >Did my server send all that? Why?? > > > >> ;; OPT PSEUDOSECTION: > >> ; EDNS: version: 0, flags:; udp: 4096 > >> ;; QUESTION SECTION: > >> ;isc.org. IN A > >> > >> ;; AUTHORITY SECTION: > >> . 348191 IN NS c.root-servers.net. > >> . 348191 IN NS d.root-servers.net. > >> . 348191 IN NS e.root-servers.net. > >> . 348191 IN NS f.root-servers.net. > >> . 348191 IN NS g.root-servers.net. > >> . 348191 IN NS h.root-servers.net. > >> . 348191 IN NS i.root-servers.net. > >> . 348191 IN NS j.root-servers.net. > >> . 348191 IN NS k.root-servers.net. > >> . 348191 IN NS l.root-servers.net. > >> . 348191 IN NS m.root-servers.net. > >> . 348191 IN NS a.root-servers.net. > >> . 348191 IN NS b.root-servers.net. > >> > >> ;; ADDITIONAL SECTION: > >> a.root-servers.net. 348191 IN A 198.41.0.4 > >> a.root-servers.net. 348191 IN AAAA 2001:503:ba3e::2:30 > >> b.root-servers.net. 348191 IN A 199.9.14.201 > >> b.root-servers.net. 348191 IN AAAA 2001:500:200::b > >> c.root-servers.net. 348191 IN A 192.33.4.12 > >> c.root-servers.net. 348191 IN AAAA 2001:500:2::c > >> d.root-servers.net. 348191 IN A 199.7.91.13 > >> d.root-servers.net. 348191 IN AAAA 2001:500:2d::d > >> e.root-servers.net. 348191 IN A 192.203.230.10 > >> e.root-servers.net. 348191 IN AAAA 2001:500:a8::e > >> f.root-servers.net. 348191 IN A 192.5.5.241 > >> f.root-servers.net. 348191 IN AAAA 2001:500:2f::f > >> g.root-servers.net. 348191 IN A 192.112.36.4 > >> g.root-servers.net. 348191 IN AAAA 2001:500:12::d0d > >> h.root-servers.net. 348191 IN A 198.97.190.53 > >> h.root-servers.net. 348191 IN AAAA 2001:500:1::53 > >> i.root-servers.net. 348191 IN A 192.36.148.17 > >> i.root-servers.net. 348191 IN AAAA 2001:7fe::53 > >> j.root-servers.net. 348191 IN A 192.58.128.30 > >> j.root-servers.net. 348191 IN AAAA 2001:503:c27::2:30 > >> k.root-servers.net. 348191 IN A 193.0.14.129 > >> k.root-servers.net. 348191 IN AAAA 2001:7fd::1 > >> l.root-servers.net. 348191 IN A 199.7.83.42 > >> l.root-servers.net. 348191 IN AAAA 2001:500:9f::42 > >> m.root-servers.net. 348191 IN A 202.12.27.33 > >> m.root-servers.net. 348191 IN AAAA 2001:dc3::35 > >> > >> ;; Query time: 150 msec > >> ;; SERVER: 66.92.74.188#53(66.92.74.188) > >> ;; WHEN: Wed Feb 10 20:31:08 PST 2021 > >> ;; MSG SIZE rcvd: 819

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Robert N. Evans

That is not what I see when I query one of the major name servers. I would guess your server is configured differently... rne@P5:~$ dig @1.1.1.1 isc.org ; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 isc.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31866 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;isc.org. IN A ;; ANSWER SECTION: isc.org. 9 IN A 149.20.1.66 ;; Query time: 24 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Thu Feb 11 10:03:30 EST 2021 ;; MSG SIZE rcvd: 52 -BE -----Original Message----- >From: Keith Wright via WLUG <wlug(a)lists.wlug.org> >Sent: Feb 11, 2021 1:04 AM >To: Worcester Linux Users' Group General Discussion <wlug(a)lists.wlug.org> >Cc: wlug(a)lists.wlug.org, Andre.Lehovich(a)gmx.com, Keith Wright <kwright(a)keithdiane.us> >Subject: [WLUG] Re: WLUG Meeting Feb 11th 2021! Topic: Good question! > >Andre Lehovich via WLUG <wlug(a)lists.wlug.org> writes: > >>> dig @66.92.74.188 isc.org >> >> Here you go, hope it's useful... > >Thank you. That's a lot of information. > >> quetzal:~ al$ dig @66.92.74.188 isc.org >> >> ; <<>> DiG 9.10.6 <<>> @66.92.74.188 isc.org >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11995 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 >> ;; WARNING: recursion requested but not available > ^^^^^^^^^ ^^^^^^^^^ ^^^ ^^^ ^^^^^^^^^ >That looks good. >I don't want to be doing recursion for you (nothing personal). > >But where did all the rest of that come from? >I've never seen anything like that! >Did my server send all that? Why?? > >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;isc.org. IN A >> >> ;; AUTHORITY SECTION: >> . 348191 IN NS c.root-servers.net. >> . 348191 IN NS d.root-servers.net. >> . 348191 IN NS e.root-servers.net. >> . 348191 IN NS f.root-servers.net. >> . 348191 IN NS g.root-servers.net. >> . 348191 IN NS h.root-servers.net. >> . 348191 IN NS i.root-servers.net. >> . 348191 IN NS j.root-servers.net. >> . 348191 IN NS k.root-servers.net. >> . 348191 IN NS l.root-servers.net. >> . 348191 IN NS m.root-servers.net. >> . 348191 IN NS a.root-servers.net. >> . 348191 IN NS b.root-servers.net. >> >> ;; ADDITIONAL SECTION: >> a.root-servers.net. 348191 IN A 198.41.0.4 >> a.root-servers.net. 348191 IN AAAA 2001:503:ba3e::2:30 >> b.root-servers.net. 348191 IN A 199.9.14.201 >> b.root-servers.net. 348191 IN AAAA 2001:500:200::b >> c.root-servers.net. 348191 IN A 192.33.4.12 >> c.root-servers.net. 348191 IN AAAA 2001:500:2::c >> d.root-servers.net. 348191 IN A 199.7.91.13 >> d.root-servers.net. 348191 IN AAAA 2001:500:2d::d >> e.root-servers.net. 348191 IN A 192.203.230.10 >> e.root-servers.net. 348191 IN AAAA 2001:500:a8::e >> f.root-servers.net. 348191 IN A 192.5.5.241 >> f.root-servers.net. 348191 IN AAAA 2001:500:2f::f >> g.root-servers.net. 348191 IN A 192.112.36.4 >> g.root-servers.net. 348191 IN AAAA 2001:500:12::d0d >> h.root-servers.net. 348191 IN A 198.97.190.53 >> h.root-servers.net. 348191 IN AAAA 2001:500:1::53 >> i.root-servers.net. 348191 IN A 192.36.148.17 >> i.root-servers.net. 348191 IN AAAA 2001:7fe::53 >> j.root-servers.net. 348191 IN A 192.58.128.30 >> j.root-servers.net. 348191 IN AAAA 2001:503:c27::2:30 >> k.root-servers.net. 348191 IN A 193.0.14.129 >> k.root-servers.net. 348191 IN AAAA 2001:7fd::1 >> l.root-servers.net. 348191 IN A 199.7.83.42 >> l.root-servers.net. 348191 IN AAAA 2001:500:9f::42 >> m.root-servers.net. 348191 IN A 202.12.27.33 >> m.root-servers.net. 348191 IN AAAA 2001:dc3::35 >> >> ;; Query time: 150 msec >> ;; SERVER: 66.92.74.188#53(66.92.74.188) >> ;; WHEN: Wed Feb 10 20:31:08 PST 2021 >> ;; MSG SIZE rcvd: 819 >> >> _______________________________________________ >> WLUG mailing list -- wlug(a)lists.wlug.org >> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >> Create Account: https://wlug.mailman3.com/accounts/signup/ >> Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >> Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/JBBKO… >_______________________________________________ >WLUG mailing list -- wlug(a)lists.wlug.org >To unsubscribe send an email to wlug-leave(a)lists.wlug.org >Create Account: https://wlug.mailman3.com/accounts/signup/ >Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/2A6P2…

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Keith Wright

Andre Lehovich via WLUG <wlug(a)lists.wlug.org> writes: >> dig @66.92.74.188 isc.org > > Here you go, hope it's useful... Thank you. That's a lot of information. > quetzal:~ al$ dig @66.92.74.188 isc.org > > ; <<>> DiG 9.10.6 <<>> @66.92.74.188 isc.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11995 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 > ;; WARNING: recursion requested but not available ^^^^^^^^^ ^^^^^^^^^ ^^^ ^^^ ^^^^^^^^^ That looks good. I don't want to be doing recursion for you (nothing personal). But where did all the rest of that come from? I've never seen anything like that! Did my server send all that? Why?? > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;isc.org. IN A > > ;; AUTHORITY SECTION: > . 348191 IN NS c.root-servers.net. > . 348191 IN NS d.root-servers.net. > . 348191 IN NS e.root-servers.net. > . 348191 IN NS f.root-servers.net. > . 348191 IN NS g.root-servers.net. > . 348191 IN NS h.root-servers.net. > . 348191 IN NS i.root-servers.net. > . 348191 IN NS j.root-servers.net. > . 348191 IN NS k.root-servers.net. > . 348191 IN NS l.root-servers.net. > . 348191 IN NS m.root-servers.net. > . 348191 IN NS a.root-servers.net. > . 348191 IN NS b.root-servers.net. > > ;; ADDITIONAL SECTION: > a.root-servers.net. 348191 IN A 198.41.0.4 > a.root-servers.net. 348191 IN AAAA 2001:503:ba3e::2:30 > b.root-servers.net. 348191 IN A 199.9.14.201 > b.root-servers.net. 348191 IN AAAA 2001:500:200::b > c.root-servers.net. 348191 IN A 192.33.4.12 > c.root-servers.net. 348191 IN AAAA 2001:500:2::c > d.root-servers.net. 348191 IN A 199.7.91.13 > d.root-servers.net. 348191 IN AAAA 2001:500:2d::d > e.root-servers.net. 348191 IN A 192.203.230.10 > e.root-servers.net. 348191 IN AAAA 2001:500:a8::e > f.root-servers.net. 348191 IN A 192.5.5.241 > f.root-servers.net. 348191 IN AAAA 2001:500:2f::f > g.root-servers.net. 348191 IN A 192.112.36.4 > g.root-servers.net. 348191 IN AAAA 2001:500:12::d0d > h.root-servers.net. 348191 IN A 198.97.190.53 > h.root-servers.net. 348191 IN AAAA 2001:500:1::53 > i.root-servers.net. 348191 IN A 192.36.148.17 > i.root-servers.net. 348191 IN AAAA 2001:7fe::53 > j.root-servers.net. 348191 IN A 192.58.128.30 > j.root-servers.net. 348191 IN AAAA 2001:503:c27::2:30 > k.root-servers.net. 348191 IN A 193.0.14.129 > k.root-servers.net. 348191 IN AAAA 2001:7fd::1 > l.root-servers.net. 348191 IN A 199.7.83.42 > l.root-servers.net. 348191 IN AAAA 2001:500:9f::42 > m.root-servers.net. 348191 IN A 202.12.27.33 > m.root-servers.net. 348191 IN AAAA 2001:dc3::35 > > ;; Query time: 150 msec > ;; SERVER: 66.92.74.188#53(66.92.74.188) > ;; WHEN: Wed Feb 10 20:31:08 PST 2021 > ;; MSG SIZE rcvd: 819 > > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/JBBKO…

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Andre Lehovich

> dig @66.92.74.188 isc.org Here you go, hope it's useful... quetzal:~ al$ dig @66.92.74.188 isc.org ; <<>> DiG 9.10.6 <<>> @66.92.74.188 isc.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11995 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;isc.org. IN A ;; AUTHORITY SECTION: . 348191 IN NS c.root-servers.net. . 348191 IN NS d.root-servers.net. . 348191 IN NS e.root-servers.net. . 348191 IN NS f.root-servers.net. . 348191 IN NS g.root-servers.net. . 348191 IN NS h.root-servers.net. . 348191 IN NS i.root-servers.net. . 348191 IN NS j.root-servers.net. . 348191 IN NS k.root-servers.net. . 348191 IN NS l.root-servers.net. . 348191 IN NS m.root-servers.net. . 348191 IN NS a.root-servers.net. . 348191 IN NS b.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 348191 IN A 198.41.0.4 a.root-servers.net. 348191 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 348191 IN A 199.9.14.201 b.root-servers.net. 348191 IN AAAA 2001:500:200::b c.root-servers.net. 348191 IN A 192.33.4.12 c.root-servers.net. 348191 IN AAAA 2001:500:2::c d.root-servers.net. 348191 IN A 199.7.91.13 d.root-servers.net. 348191 IN AAAA 2001:500:2d::d e.root-servers.net. 348191 IN A 192.203.230.10 e.root-servers.net. 348191 IN AAAA 2001:500:a8::e f.root-servers.net. 348191 IN A 192.5.5.241 f.root-servers.net. 348191 IN AAAA 2001:500:2f::f g.root-servers.net. 348191 IN A 192.112.36.4 g.root-servers.net. 348191 IN AAAA 2001:500:12::d0d h.root-servers.net. 348191 IN A 198.97.190.53 h.root-servers.net. 348191 IN AAAA 2001:500:1::53 i.root-servers.net. 348191 IN A 192.36.148.17 i.root-servers.net. 348191 IN AAAA 2001:7fe::53 j.root-servers.net. 348191 IN A 192.58.128.30 j.root-servers.net. 348191 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 348191 IN A 193.0.14.129 k.root-servers.net. 348191 IN AAAA 2001:7fd::1 l.root-servers.net. 348191 IN A 199.7.83.42 l.root-servers.net. 348191 IN AAAA 2001:500:9f::42 m.root-servers.net. 348191 IN A 202.12.27.33 m.root-servers.net. 348191 IN AAAA 2001:dc3::35 ;; Query time: 150 msec ;; SERVER: 66.92.74.188#53(66.92.74.188) ;; WHEN: Wed Feb 10 20:31:08 PST 2021 ;; MSG SIZE rcvd: 819

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Keith Wright

I hope to make it. I'll have to borrow Diane's laptop. My Linux laptop makes a fine computer, but a bad television It says "Topic: Good question!" So here's my good question: I run a name server (DNS). A few days ago it started getting abut 100 requests/min from many different IP addresses all for isc.org. Why are they asking me? I believe I have it set up so that queries from inside the house are so-called "recurive"--- it searches the internet for an answer, but queries from outside are anwered only with info it already has. I am not sure if that means it only answer queries for which it authoritative, or if it also anwers if it has the data cached. I would like it to just blow off any queries for which it is not authoritative. Tell where to send mail for @keithdiane.us and not even answer otherwise. It is remarkably difficult to get it to put replies into the log file, even if it is logging the queries. Could somebody run the following and tell me the results? dig @66.92.74.188 isc.org (that's my IP address) -- Keith

Feb. 11, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Robert N. Evans

I don't want to join the endian wars. So I'll comment on something else. Stratus did not support Itanium because they follow rather than lead the market. When a replacement for PA-RISC was considered at Stratus we did look at Itanium. I recall studying the FW then called "EFI" around 2003 when I was in the VOS group. For the in-house VOS OS, Stratus would need compilers for PL/I and C and a modified linker to get to Itanium. Stratus never made this investment. What the VOS group did was to port to x86. Today VOS is still a 32-bit OS that runs on Motorola 68K, i860, PA-RISC and x86. This is unlikely to ever change for VOS as the compiler and linker tech leads have left Stratus. For the other three OS's supported by Stratus, Windows, Linux, VMware ESX, outsiders, not Stratus, would or would not be porting their OS to Itanium. (As was the case for amd64). Since the Stratus value add is to take applications coded to run on commodity HW and make the apps highly reliable by running on Stratus HW, Stratus would not move to Itanium until the customers already were developing to that platform. -- One more comment on a different topic: > >I personally play around with ATTiny85 and ATTiny84 MCUs when I get a >chance. Slowly looking at STM8 and STM32 stuff as well. And of >course the Arduino AVR stuff. > Me too, but somewhat bigger/faster MCUs. I still occasionally code in C, but it is more productive with high level interpreted languages on these chips. Lately I'm very excited about esp8266 and CircuitPython. FYI, A programmer's intro to esp8266: https://tttapa.github.io/ESP8266/Chap01%20-%20ESP8266.html -BE

Feb. 5, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

John, I read what Linus wrote and I think the most important paragraph is the last two. This "deficiency" in the Alpha design was not that consequential to anyone but a very small number of people, and still allowed the Alpha to be the world's fastest microprocessor for (if I remember correctly) eight years in a row according to the Guinness Book of Records. As to the little vs big endian issues, the worst part was in reading undefined data across the network. What do I mean by "undefined data"? o The union statement in "C" o The equivalence statement in FORTRAN o The Linkage section in Cobol All statements that allow you to write the same data looking at it in different ways. If you write out a "block" of Integers into a file, there is no way that a system reading that file some time later could tell if those integers were written by a little endian system or a big endian system, so the Integers would be read incorrectly. NFS made it worse....much worse, but it was bad before NFS. md On Thu, Feb 4, 2021 at 5:37 PM John Stoffel <john(a)stoffel.org> wrote: > >>>>> "Jon" == Jon \"maddog\" Hall <jon.maddog.hall(a)gmail.com> writes: > > Jon> John, > >> Yes, but I don't properly recall if the Itanium design was started > >> before AMD64 came or as a reaction to the AMD64. Haven't done any > >> research for the real timelines. > > Jon> Two single-line searches found that the Itanium was launched in > Jon> 2001 and the AMD x64 was launched in 2003. > > Been neck deep in SFLT tape restore wrangling today. Whee!!! > > >> It's a shame the Alpha architecture didn't make it, even though it did > >> have some bad design decisions inside it's ISA and internal > >> architecture. It was still a pretty nice and clean 64-bit design. As > >> I recall, it's mostly the memory ordering around byte accesses that > >> are the problem. > > Jon> This is the first I have heard of these bad decisions. Would you > care to elaborate? > > It's in regards to memory ordering. See this LKML post by Linus on > the topic. This is what I'm talking about mostly. > > https://lkml.org/lkml/2012/2/1/521 > > > Jon> The memory ordering around byte accesses might have been because > Jon> the Alpha was designed to be both little endian and big endian. > Jon> So were the MIPS chips. While many vendors supported only big > Jon> endian (Motorola, SPARC, etc.) DEC had been supporting little > Jon> endian in their PDP-11s, VAX, MIPS and Alphas for data > Jon> compatibility. DEC supported little endian because it was > Jon> cheaper electronically to have the data held in that fashion. > > Very much could be that is the reason. I don't know. > > Jon> Sun made much fun of DEC for years having Unix systems that were > Jon> little endian instead of big endian like "real workstations". I > Jon> kept asking them about these "Intel things" which were little > Jon> endian too. Sun sneered at me and told me that "Intel chips > Jon> were not used in real computers".....that is until they ported > Jon> Solaris to Intel and tried to mix them into their network. Then > Jon> I took real glee in asking them how they had data compatibility > Jon> across NFS between SPARC and Intel. > > Gah, all the problems with writing socket code and having to do > translations from Network Byte Ordering to Host Byte Ordering. > hton[ls]() and the inverse. > > Jon> As I said, you are the first to mention to me these bad > Jon> decisions. I am curious to know what they are. > > It's in terms of memory ordering on access. See the above link. >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

>More obscure. It has to do with how memory accesses to bytes are >handled on the Alpha architecture. They're not very quick, because >the Alpha wants to do all memory access in 32bit chunks. "Quick" is in the eye of the beholder. Yes, the Alpha tended to access data in 32 bit "chunks" to get it into the registers. Being a RISC processor it was not as rich in data access on a byte level. On the other hand other CISC processors also accessed data on a 32-bit level, just that their instruction sets used microcode to make it look like they were only accessing a byte. The trade off was in executing multiple RISC instructions to one microcoded CISC instruction. Would this bother a kernel developer writing a couple of lines of assembly language down at the very lowest level of the kernel....probably. On the other hand for years Linus talked about the Alpha as the best architecture chip he knew, so it could not have been too bad. md On Thu, Feb 4, 2021 at 5:29 PM John Stoffel <john(a)stoffel.org> wrote: > >>>>> "Keith" == Keith Wright <kwright(a)keithdiane.us> writes: > > Keith> John Stoffel via WLUG <wlug(a)lists.wlug.org> writes: > >> I recall, it's mostly the memory ordering around byte accesses that > >> are the problem. > > Keith> Are you saying that the Big Endian vs Little Endian flame war > Keith> actually had consequences in the Real World? > > It did, and still does. MIPS processors can be BE or LE (Big/Little > Endian) depending on how you configure them as I understand, though > this is more the smaller micro-controllers used in embedded stuff. > > I personally play around with ATTiny85 and ATTiny84 MCUs when I get a > chance. Slowly looking at STM8 and STM32 stuff as well. And of > course the Arduino AVR stuff. > > Keith> Or something even more obscure? > > More obscure. It has to do with how memory accesses to bytes are > handled on the Alpha architecture. They're not very quick, because > the Alpha wants to do all memory access in 32bit chunks. > > I honestly don't recall all the full details. You can find info in > the LKML (Linux Kernel Mailing List) which discuss this over the > years. Looks for Posts by Linus Torvalds which also mention Alpha. > Interesting reading. > >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by John Stoffel

>>>>> "Jon" == Jon \"maddog\" Hall <jon.maddog.hall(a)gmail.com> writes: Jon> John, >> Yes, but I don't properly recall if the Itanium design was started >> before AMD64 came or as a reaction to the AMD64. Haven't done any >> research for the real timelines. Jon> Two single-line searches found that the Itanium was launched in Jon> 2001 and the AMD x64 was launched in 2003. Been neck deep in SFLT tape restore wrangling today. Whee!!! >> It's a shame the Alpha architecture didn't make it, even though it did >> have some bad design decisions inside it's ISA and internal >> architecture. It was still a pretty nice and clean 64-bit design. As >> I recall, it's mostly the memory ordering around byte accesses that >> are the problem. Jon> This is the first I have heard of these bad decisions. Would you care to elaborate? It's in regards to memory ordering. See this LKML post by Linus on the topic. This is what I'm talking about mostly. https://lkml.org/lkml/2012/2/1/521 Jon> The memory ordering around byte accesses might have been because Jon> the Alpha was designed to be both little endian and big endian. Jon> So were the MIPS chips. While many vendors supported only big Jon> endian (Motorola, SPARC, etc.) DEC had been supporting little Jon> endian in their PDP-11s, VAX, MIPS and Alphas for data Jon> compatibility. DEC supported little endian because it was Jon> cheaper electronically to have the data held in that fashion. Very much could be that is the reason. I don't know. Jon> Sun made much fun of DEC for years having Unix systems that were Jon> little endian instead of big endian like "real workstations". I Jon> kept asking them about these "Intel things" which were little Jon> endian too. Sun sneered at me and told me that "Intel chips Jon> were not used in real computers".....that is until they ported Jon> Solaris to Intel and tried to mix them into their network. Then Jon> I took real glee in asking them how they had data compatibility Jon> across NFS between SPARC and Intel. Gah, all the problems with writing socket code and having to do translations from Network Byte Ordering to Host Byte Ordering. hton[ls]() and the inverse. Jon> As I said, you are the first to mention to me these bad Jon> decisions. I am curious to know what they are. It's in terms of memory ordering on access. See the above link.

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by John Stoffel

>>>>> "Keith" == Keith Wright <kwright(a)keithdiane.us> writes: Keith> John Stoffel via WLUG <wlug(a)lists.wlug.org> writes: >> I recall, it's mostly the memory ordering around byte accesses that >> are the problem. Keith> Are you saying that the Big Endian vs Little Endian flame war Keith> actually had consequences in the Real World? It did, and still does. MIPS processors can be BE or LE (Big/Little Endian) depending on how you configure them as I understand, though this is more the smaller micro-controllers used in embedded stuff. I personally play around with ATTiny85 and ATTiny84 MCUs when I get a chance. Slowly looking at STM8 and STM32 stuff as well. And of course the Arduino AVR stuff. Keith> Or something even more obscure? More obscure. It has to do with how memory accesses to bytes are handled on the Alpha architecture. They're not very quick, because the Alpha wants to do all memory access in 32bit chunks. I honestly don't recall all the full details. You can find info in the LKML (Linux Kernel Mailing List) which discuss this over the years. Looks for Posts by Linus Torvalds which also mention Alpha. Interesting reading.

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

John, >Yes, but I don't properly recall if the Itanium design was started >before AMD64 came or as a reaction to the AMD64. Haven't done any >research for the real timelines. Two single-line searches found that the Itanium was launched in 2001 and the AMD x64 was launched in 2003. >It's a shame the Alpha architecture didn't make it, even though it did >have some bad design decisions inside it's ISA and internal >architecture. It was still a pretty nice and clean 64-bit design. As >I recall, it's mostly the memory ordering around byte accesses that >are the problem. This is the first I have heard of these bad decisions. Would you care to elaborate? The memory ordering around byte accesses might have been because the Alpha was designed to be both little endian and big endian. So were the MIPS chips. While many vendors supported only big endian (Motorola, SPARC, etc.) DEC had been supporting little endian in their PDP-11s, VAX, MIPS and Alphas for data compatibility. DEC supported little endian because it was cheaper electronically to have the data held in that fashion. Sun made much fun of DEC for years having Unix systems that were little endian instead of big endian like "real workstations". I kept asking them about these "Intel things" which were little endian too. Sun sneered at me and told me that "Intel chips were not used in real computers".....that is until they ported Solaris to Intel and tried to mix them into their network. Then I took real glee in asking them how they had data compatibility across NFS between SPARC and Intel. As I said, you are the first to mention to me these bad decisions. I am curious to know what they are. md On Thu, Feb 4, 2021 at 4:56 PM John Stoffel <john(a)stoffel.org> wrote: > >>>>> "Jon" == Jon \"maddog\" Hall <jon.maddog.hall(a)gmail.com> writes: > > Yes, but I don't properly recall if the Itanium design was started > before AMD64 came or as a reaction to the AMD64. Haven't done any > research for the real timelines. > > It's a shame the Alpha architecture didn't make it, even though it did > have some bad design decisions inside it's ISA and internal > architecture. It was still a pretty nice and clean 64-bit design. As > I recall, it's mostly the memory ordering around byte accesses that > are the problem. > > > Jon> Allow me translate what you said: > > Jon> "As I recall, Itanium was Intel's attempt to bi-furcate the market and > Jon> keep 32bit for desktops and such, and to make their 64bit systems for > Jon> workstations and such a seperate product so they could take more > Jon> control of the motherboard, bios, etc" > > Jon> to > > Jon> "Itanium was Intel's abortive attempt to block AMD from making a > Jon> better, faster, cheaper 64-bit CISC product." > > Jon> Shorter, and more to the point. > > > > Jon> On Thu, Feb 4, 2021 at 4:13 PM John Stoffel <john(a)stoffel.org> wrote: > > Jon> As I recall, Itanium was Intel's attempt to bi-furcate the market > and > Jon> keep 32bit for desktops and such, and to make their 64bit systems > for > Jon> workstations and such a seperate product so they could take more > Jon> control of the motherboard, bios, etc. > > Jon> Then AMD came out with the AMD64 64-bit extenstions to the Intel > 386 > Jon> (486?) instruction set, since they had an architectural license > to the > Jon> ISA, so they just extended it and started shipping cheaper CPUs > and > Jon> chipsets that could easily suport more than 4gb of RAM, without > Jon> requiring people to do major re-compiles of their software. > Jon> Especially since it would support 32bit applications in a 64bit OS > Jon> without *any* recompile needed. > > Jon> They ate Intel's lunch. Which is why the Pentium 4 (I think) was > such > Jon> a monster chip in terms of CPU GHz and heat, because they were > trying > Jon> to catchup with the Opteron and other AMD chips. > > Jon> John > > Tim> My perspective was from working at Stratus. Continuum at the time was > our flagship line > Jon> of servers > Tim> that ran on PA-RISC and with Itanium it was clear the end of the line > for PA-RISC was > Jon> coming. > > Tim> Bob Evans and others who were more intimately involved can probably > explain it better, > Jon> but I > Tim> remember Stratus getting a couple Itanium development workstations > and my recollection > Jon> was that > Tim> the engineers weren't impressed. > Tim> It wasn't a fundamental improvement on PA-RISC as far as they could > tell. Ultimately VOS > Jon> was > Tim> ported to Xeon and the rest is history. I'm sure someone somewhere is > still happily > Jon> running > Tim> PA-RISC based Stratus servers, but I have to imagine that number > dwindles each year. > > Tim> Personally I have a hypothesis that Intel had really put it's bets on > Xeon and wasn't > Jon> really that > Tim> invested in Itanium. What it did do was get HP out of the HPC market. > It's fair to say > Jon> that Xeon > Tim> based systems running Linux pretty much put the coffin nails in MIPS, > PA-RISC and > Jon> ultimately Sparc > Tim> and likely a few others I don't know about and with it the various > operating systems that > Jon> didn't > Tim> get ported to Xeon. > > Tim> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall < > jon.maddog.hall(a)gmail.com> wrote: > > Tim> I still vividly remember my boss showing me the plans for > support of Intel's Itanium > Tim> processor. > > Tim> As someone who taught operating systems and compiler design for > a number of years I > Jon> still > Tim> remember my shock that THIS was the answer for Intel's 64-bit > chip....an Ultra-Wide > Tim> Instruction set. > > Tim> I wailed away about how all of this was WRONG, WRONG, > WRONG.....mostly because I had > Jon> spent the > Tim> past six months proving why even a regular CISC system was the > wrong answer, and here > Jon> Intel > Tim> was going in the opposite direction. > > Tim> After twenty minutes of me fuming my boss simply grinned, > shrugged his shoulders and > Jon> left my > Tim> office. > > Tim> While I was proud of the fact that the Alpha processor was so > prominent in the > Jon> production of > Tim> the movie "Titanic"......now I had to deal with a real life > "Itanic"....watching it > Jon> sink. > > Tim> md > > Tim> P.S. It was only a month or so after, I think, that AMD came > out with a reasonable > Jon> extension > Tim> to the i86 architecture....which (although it was not RISC) I > was reasonably happy > Jon> with. > > Tim> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG < > wlug(a)lists.wlug.org> wrote: > > Tim> Hey Everybody, > > Tim> We've got a meeting next week on the 11th at our same time > (7pm) > > Tim> As for a topic, if somebody would like to present something, > I'd be up for it. > Tim> I figure we'd all toast the depreciation of Itanium in the > linux kernel. Good > Jon> riddance! > > Tim> We'll definitely be talking about the PI4 Nano!! > > Tim> As usual, I'm sure other topics will organically surface. > > Tim> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA > > Tim> Later, > Tim> Tim. > Tim> -- > Tim> I am leery of the allegiances of any politician who refers > to their constituents > Jon> as > Tim> "consumers". > Tim> _______________________________________________ > Tim> WLUG mailing list -- wlug(a)lists.wlug.org > Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ > Tim> Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Tim> Web Forum/Archive: > Tim> > Jon> > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… > > Tim> -- > Tim> I am leery of the allegiances of any politician who refers to their > constituents as > Jon> "consumers". > > Tim> _______________________________________________ > Tim> WLUG mailing list -- wlug(a)lists.wlug.org > Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ > Tim> Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Tim> Web Forum/Archive: > Jon> > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ZDSLS… > >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Keith Wright

John Stoffel via WLUG <wlug(a)lists.wlug.org> writes: > I recall, it's mostly the memory ordering around byte accesses that > are the problem. Are you saying that the Big Endian vs Little Endian flame war actually had consequences in the Real World? Or something even more obscure? -- Keith

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by John Stoffel

>>>>> "Jon" == Jon \"maddog\" Hall <jon.maddog.hall(a)gmail.com> writes: Yes, but I don't properly recall if the Itanium design was started before AMD64 came or as a reaction to the AMD64. Haven't done any research for the real timelines. It's a shame the Alpha architecture didn't make it, even though it did have some bad design decisions inside it's ISA and internal architecture. It was still a pretty nice and clean 64-bit design. As I recall, it's mostly the memory ordering around byte accesses that are the problem. Jon> Allow me translate what you said: Jon> "As I recall, Itanium was Intel's attempt to bi-furcate the market and Jon> keep 32bit for desktops and such, and to make their 64bit systems for Jon> workstations and such a seperate product so they could take more Jon> control of the motherboard, bios, etc" Jon> to Jon> "Itanium was Intel's abortive attempt to block AMD from making a Jon> better, faster, cheaper 64-bit CISC product." Jon> Shorter, and more to the point. Jon> On Thu, Feb 4, 2021 at 4:13 PM John Stoffel <john(a)stoffel.org> wrote: Jon> As I recall, Itanium was Intel's attempt to bi-furcate the market and Jon> keep 32bit for desktops and such, and to make their 64bit systems for Jon> workstations and such a seperate product so they could take more Jon> control of the motherboard, bios, etc. Jon> Then AMD came out with the AMD64 64-bit extenstions to the Intel 386 Jon> (486?) instruction set, since they had an architectural license to the Jon> ISA, so they just extended it and started shipping cheaper CPUs and Jon> chipsets that could easily suport more than 4gb of RAM, without Jon> requiring people to do major re-compiles of their software. Jon> Especially since it would support 32bit applications in a 64bit OS Jon> without *any* recompile needed. Jon> They ate Intel's lunch. Which is why the Pentium 4 (I think) was such Jon> a monster chip in terms of CPU GHz and heat, because they were trying Jon> to catchup with the Opteron and other AMD chips. Jon> John Tim> My perspective was from working at Stratus. Continuum at the time was our flagship line Jon> of servers Tim> that ran on PA-RISC and with Itanium it was clear the end of the line for PA-RISC was Jon> coming. Tim> Bob Evans and others who were more intimately involved can probably explain it better, Jon> but I Tim> remember Stratus getting a couple Itanium development workstations and my recollection Jon> was that Tim> the engineers weren't impressed. Tim> It wasn't a fundamental improvement on PA-RISC as far as they could tell. Ultimately VOS Jon> was Tim> ported to Xeon and the rest is history. I'm sure someone somewhere is still happily Jon> running Tim> PA-RISC based Stratus servers, but I have to imagine that number dwindles each year. Tim> Personally I have a hypothesis that Intel had really put it's bets on Xeon and wasn't Jon> really that Tim> invested in Itanium. What it did do was get HP out of the HPC market. It's fair to say Jon> that Xeon Tim> based systems running Linux pretty much put the coffin nails in MIPS, PA-RISC and Jon> ultimately Sparc Tim> and likely a few others I don't know about and with it the various operating systems that Jon> didn't Tim> get ported to Xeon. Tim> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> wrote: Tim> I still vividly remember my boss showing me the plans for support of Intel's Itanium Tim> processor. Tim> As someone who taught operating systems and compiler design for a number of years I Jon> still Tim> remember my shock that THIS was the answer for Intel's 64-bit chip....an Ultra-Wide Tim> Instruction set. Tim> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly because I had Jon> spent the Tim> past six months proving why even a regular CISC system was the wrong answer, and here Jon> Intel Tim> was going in the opposite direction. Tim> After twenty minutes of me fuming my boss simply grinned, shrugged his shoulders and Jon> left my Tim> office. Tim> While I was proud of the fact that the Alpha processor was so prominent in the Jon> production of Tim> the movie "Titanic"......now I had to deal with a real life "Itanic"....watching it Jon> sink. Tim> md Tim> P.S. It was only a month or so after, I think, that AMD came out with a reasonable Jon> extension Tim> to the i86 architecture....which (although it was not RISC) I was reasonably happy Jon> with. Tim> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> wrote: Tim> Hey Everybody, Tim> We've got a meeting next week on the 11th at our same time (7pm) Tim> As for a topic, if somebody would like to present something, I'd be up for it. Tim> I figure we'd all toast the depreciation of Itanium in the linux kernel. Good Jon> riddance! Tim> We'll definitely be talking about the PI4 Nano!! Tim> As usual, I'm sure other topics will organically surface. Tim> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA Tim> Later, Tim> Tim. Tim> -- Tim> I am leery of the allegiances of any politician who refers to their constituents Jon> as Tim> "consumers". Tim> _______________________________________________ Tim> WLUG mailing list -- wlug(a)lists.wlug.org Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ Tim> Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Tim> Web Forum/Archive: Tim> Jon> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… Tim> -- Tim> I am leery of the allegiances of any politician who refers to their constituents as Jon> "consumers". Tim> _______________________________________________ Tim> WLUG mailing list -- wlug(a)lists.wlug.org Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ Tim> Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Tim> Web Forum/Archive: Jon> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ZDSLS…

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

I asked the engineering manager about the Itanium and what he remembered was there was a skunkworks project in ZKO that was trying to port Digital Unix to the Itanium, "Mostly because of the IP management constraints/restrictions from Intel." (his words). DEC already had the fastest microcomputer processor in the world (the Alpha), and we were not going to confuse our application base on what they should port to and support. And to show that I was not a RISC bigot (at least not at the time), I just smiled when I saw what AMD did to create their 64-bit instruction set. It was sweet. md On Thu, Feb 4, 2021 at 3:30 PM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> wrote: > The port of Tru64 to Itanium must have been after I left. I do not know > anyone in the Tru64 product management that would have given any life to > that project. No life. None. > > I can ask one of the engineering managers of that time. > > md > > On Thu, Feb 4, 2021 at 2:13 PM Jared Greenwald <greenwaldjared(a)gmail.com> > wrote: > >> Still boggles my mind the amount of money HP spent on Itanium hardware >> back after they acquired Compaq/Tru64 only to basically abandon the whole >> thing and lay off everyone. >> >> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall via WLUG < >> wlug(a)lists.wlug.org> wrote: >> >>> I still vividly remember my boss showing me the plans for support of >>> Intel's Itanium processor. >>> >>> As someone who taught operating systems and compiler design for a number >>> of years I still remember my shock that THIS was the answer for Intel's >>> 64-bit chip....an Ultra-Wide Instruction set. >>> >>> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly >>> because I had spent the past six months proving why even a regular CISC >>> system was the wrong answer, and here Intel was going in the opposite >>> direction. >>> >>> After twenty minutes of me fuming my boss simply grinned, shrugged his >>> shoulders and left my office. >>> >>> While I was proud of the fact that the Alpha processor was so prominent >>> in the production of the movie "Titanic"......now I had to deal with a real >>> life "Itanic"....watching it sink. >>> >>> md >>> >>> P.S. It was only a month or so after, I think, that AMD came out with a >>> reasonable extension to the i86 architecture....which (although it was not >>> RISC) I was reasonably happy with. >>> >>> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> >>> wrote: >>> >>>> Hey Everybody, >>>> >>>> We've got a meeting next week on the 11th at our same time (7pm) >>>> >>>> As for a topic, if somebody would like to present something, I'd be >>>> up for it. >>>> I figure we'd all toast the depreciation of Itanium in the linux >>>> kernel. Good riddance! >>>> >>>> We'll definitely be talking about the PI4 Nano!! >>>> >>>> As usual, I'm sure other topics will organically surface. >>>> >>>> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >>>> >>>> Later, >>>> Tim. >>>> -- >>>> I am leery of the allegiances of any politician who refers to their >>>> constituents as "consumers". >>>> _______________________________________________ >>>> WLUG mailing list -- wlug(a)lists.wlug.org >>>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>>> Change Settings: >>>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>>> Web Forum/Archive: >>>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >>>> >>> _______________________________________________ >>> WLUG mailing list -- wlug(a)lists.wlug.org >>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>> Change Settings: >>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>> Web Forum/Archive: >>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/DM5K6… >>> >>

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

John, Allow me translate what you said: "As I recall, Itanium was Intel's attempt to bi-furcate the market and keep 32bit for desktops and such, and to make their 64bit systems for workstations and such a seperate product so they could take more control of the motherboard, bios, etc" to "Itanium was Intel's abortive attempt to block AMD from making a better, faster, cheaper 64-bit CISC product." Shorter, and more to the point. md On Thu, Feb 4, 2021 at 4:13 PM John Stoffel <john(a)stoffel.org> wrote: > > As I recall, Itanium was Intel's attempt to bi-furcate the market and > keep 32bit for desktops and such, and to make their 64bit systems for > workstations and such a seperate product so they could take more > control of the motherboard, bios, etc. > > Then AMD came out with the AMD64 64-bit extenstions to the Intel 386 > (486?) instruction set, since they had an architectural license to the > ISA, so they just extended it and started shipping cheaper CPUs and > chipsets that could easily suport more than 4gb of RAM, without > requiring people to do major re-compiles of their software. > Especially since it would support 32bit applications in a 64bit OS > without *any* recompile needed. > > They ate Intel's lunch. Which is why the Pentium 4 (I think) was such > a monster chip in terms of CPU GHz and heat, because they were trying > to catchup with the Opteron and other AMD chips. > > John > > > Tim> My perspective was from working at Stratus. Continuum at the time was > our flagship line of servers > Tim> that ran on PA-RISC and with Itanium it was clear the end of the line > for PA-RISC was coming. > > Tim> Bob Evans and others who were more intimately involved can probably > explain it better, but I > Tim> remember Stratus getting a couple Itanium development workstations > and my recollection was that > Tim> the engineers weren't impressed. > Tim> It wasn't a fundamental improvement on PA-RISC as far as they could > tell. Ultimately VOS was > Tim> ported to Xeon and the rest is history. I'm sure someone somewhere is > still happily running > Tim> PA-RISC based Stratus servers, but I have to imagine that number > dwindles each year. > > Tim> Personally I have a hypothesis that Intel had really put it's bets on > Xeon and wasn't really that > Tim> invested in Itanium. What it did do was get HP out of the HPC market. > It's fair to say that Xeon > Tim> based systems running Linux pretty much put the coffin nails in MIPS, > PA-RISC and ultimately Sparc > Tim> and likely a few others I don't know about and with it the various > operating systems that didn't > Tim> get ported to Xeon. > > Tim> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall < > jon.maddog.hall(a)gmail.com> wrote: > > Tim> I still vividly remember my boss showing me the plans for support > of Intel's Itanium > Tim> processor. > > Tim> As someone who taught operating systems and compiler design for a > number of years I still > Tim> remember my shock that THIS was the answer for Intel's 64-bit > chip....an Ultra-Wide > Tim> Instruction set. > > Tim> I wailed away about how all of this was WRONG, WRONG, > WRONG.....mostly because I had spent the > Tim> past six months proving why even a regular CISC system was the > wrong answer, and here Intel > Tim> was going in the opposite direction. > > Tim> After twenty minutes of me fuming my boss simply grinned, > shrugged his shoulders and left my > Tim> office. > > Tim> While I was proud of the fact that the Alpha processor was so > prominent in the production of > Tim> the movie "Titanic"......now I had to deal with a real life > "Itanic"....watching it sink. > > Tim> md > > Tim> P.S. It was only a month or so after, I think, that AMD came out > with a reasonable extension > Tim> to the i86 architecture....which (although it was not RISC) I was > reasonably happy with. > > Tim> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG < > wlug(a)lists.wlug.org> wrote: > > Tim> Hey Everybody, > > Tim> We've got a meeting next week on the 11th at our same time > (7pm) > > Tim> As for a topic, if somebody would like to present something, > I'd be up for it. > Tim> I figure we'd all toast the depreciation of Itanium in the > linux kernel. Good riddance! > > Tim> We'll definitely be talking about the PI4 Nano!! > > Tim> As usual, I'm sure other topics will organically surface. > > Tim> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA > > Tim> Later, > Tim> Tim. > Tim> -- > Tim> I am leery of the allegiances of any politician who refers to > their constituents as > Tim> "consumers". > Tim> _______________________________________________ > Tim> WLUG mailing list -- wlug(a)lists.wlug.org > Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ > Tim> Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Tim> Web Forum/Archive: > Tim> > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… > > Tim> -- > Tim> I am leery of the allegiances of any politician who refers to their > constituents as "consumers". > > Tim> _______________________________________________ > Tim> WLUG mailing list -- wlug(a)lists.wlug.org > Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ > Tim> Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Tim> Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ZDSLS… >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by John Stoffel

As I recall, Itanium was Intel's attempt to bi-furcate the market and keep 32bit for desktops and such, and to make their 64bit systems for workstations and such a seperate product so they could take more control of the motherboard, bios, etc. Then AMD came out with the AMD64 64-bit extenstions to the Intel 386 (486?) instruction set, since they had an architectural license to the ISA, so they just extended it and started shipping cheaper CPUs and chipsets that could easily suport more than 4gb of RAM, without requiring people to do major re-compiles of their software. Especially since it would support 32bit applications in a 64bit OS without *any* recompile needed. They ate Intel's lunch. Which is why the Pentium 4 (I think) was such a monster chip in terms of CPU GHz and heat, because they were trying to catchup with the Opteron and other AMD chips. John Tim> My perspective was from working at Stratus. Continuum at the time was our flagship line of servers Tim> that ran on PA-RISC and with Itanium it was clear the end of the line for PA-RISC was coming. Tim> Bob Evans and others who were more intimately involved can probably explain it better, but I Tim> remember Stratus getting a couple Itanium development workstations and my recollection was that Tim> the engineers weren't impressed. Tim> It wasn't a fundamental improvement on PA-RISC as far as they could tell. Ultimately VOS was Tim> ported to Xeon and the rest is history. I'm sure someone somewhere is still happily running Tim> PA-RISC based Stratus servers, but I have to imagine that number dwindles each year. Tim> Personally I have a hypothesis that Intel had really put it's bets on Xeon and wasn't really that Tim> invested in Itanium. What it did do was get HP out of the HPC market. It's fair to say that Xeon Tim> based systems running Linux pretty much put the coffin nails in MIPS, PA-RISC and ultimately Sparc Tim> and likely a few others I don't know about and with it the various operating systems that didn't Tim> get ported to Xeon. Tim> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> wrote: Tim> I still vividly remember my boss showing me the plans for support of Intel's Itanium Tim> processor. Tim> As someone who taught operating systems and compiler design for a number of years I still Tim> remember my shock that THIS was the answer for Intel's 64-bit chip....an Ultra-Wide Tim> Instruction set. Tim> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly because I had spent the Tim> past six months proving why even a regular CISC system was the wrong answer, and here Intel Tim> was going in the opposite direction. Tim> After twenty minutes of me fuming my boss simply grinned, shrugged his shoulders and left my Tim> office. Tim> While I was proud of the fact that the Alpha processor was so prominent in the production of Tim> the movie "Titanic"......now I had to deal with a real life "Itanic"....watching it sink. Tim> md Tim> P.S. It was only a month or so after, I think, that AMD came out with a reasonable extension Tim> to the i86 architecture....which (although it was not RISC) I was reasonably happy with. Tim> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> wrote: Tim> Hey Everybody, Tim> We've got a meeting next week on the 11th at our same time (7pm) Tim> As for a topic, if somebody would like to present something, I'd be up for it. Tim> I figure we'd all toast the depreciation of Itanium in the linux kernel. Good riddance! Tim> We'll definitely be talking about the PI4 Nano!! Tim> As usual, I'm sure other topics will organically surface. Tim> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA Tim> Later, Tim> Tim. Tim> -- Tim> I am leery of the allegiances of any politician who refers to their constituents as Tim> "consumers". Tim> _______________________________________________ Tim> WLUG mailing list -- wlug(a)lists.wlug.org Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ Tim> Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Tim> Web Forum/Archive: Tim> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… Tim> -- Tim> I am leery of the allegiances of any politician who refers to their constituents as "consumers". Tim> _______________________________________________ Tim> WLUG mailing list -- wlug(a)lists.wlug.org Tim> To unsubscribe send an email to wlug-leave(a)lists.wlug.org Tim> Create Account: https://wlug.mailman3.com/accounts/signup/ Tim> Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Tim> Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ZDSLS…

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

I think that "TruCluster" was a layered product on top of "Tru64". I think that was slightly after my time at DEC also. I left in 1999. md On Thu, Feb 4, 2021 at 3:58 PM Jared Greenwald <greenwaldjared(a)gmail.com> wrote: > Sorry I was more thinking of TruCluster. I know we have a lot of contacts > in common from that time. > > On Thu, Feb 4, 2021, 3:30 PM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> > wrote: > >> The port of Tru64 to Itanium must have been after I left. I do not know >> anyone in the Tru64 product management that would have given any life to >> that project. No life. None. >> >> I can ask one of the engineering managers of that time. >> >> md >> >> On Thu, Feb 4, 2021 at 2:13 PM Jared Greenwald <greenwaldjared(a)gmail.com> >> wrote: >> >>> Still boggles my mind the amount of money HP spent on Itanium hardware >>> back after they acquired Compaq/Tru64 only to basically abandon the whole >>> thing and lay off everyone. >>> >>> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall via WLUG < >>> wlug(a)lists.wlug.org> wrote: >>> >>>> I still vividly remember my boss showing me the plans for support of >>>> Intel's Itanium processor. >>>> >>>> As someone who taught operating systems and compiler design for a >>>> number of years I still remember my shock that THIS was the answer for >>>> Intel's 64-bit chip....an Ultra-Wide Instruction set. >>>> >>>> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly >>>> because I had spent the past six months proving why even a regular CISC >>>> system was the wrong answer, and here Intel was going in the opposite >>>> direction. >>>> >>>> After twenty minutes of me fuming my boss simply grinned, shrugged his >>>> shoulders and left my office. >>>> >>>> While I was proud of the fact that the Alpha processor was so prominent >>>> in the production of the movie "Titanic"......now I had to deal with a real >>>> life "Itanic"....watching it sink. >>>> >>>> md >>>> >>>> P.S. It was only a month or so after, I think, that AMD came out with >>>> a reasonable extension to the i86 architecture....which (although it was >>>> not RISC) I was reasonably happy with. >>>> >>>> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> >>>> wrote: >>>> >>>>> Hey Everybody, >>>>> >>>>> We've got a meeting next week on the 11th at our same time (7pm) >>>>> >>>>> As for a topic, if somebody would like to present something, I'd be >>>>> up for it. >>>>> I figure we'd all toast the depreciation of Itanium in the linux >>>>> kernel. Good riddance! >>>>> >>>>> We'll definitely be talking about the PI4 Nano!! >>>>> >>>>> As usual, I'm sure other topics will organically surface. >>>>> >>>>> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >>>>> >>>>> Later, >>>>> Tim. >>>>> -- >>>>> I am leery of the allegiances of any politician who refers to their >>>>> constituents as "consumers". >>>>> _______________________________________________ >>>>> WLUG mailing list -- wlug(a)lists.wlug.org >>>>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>>>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>>>> Change Settings: >>>>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>>>> Web Forum/Archive: >>>>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >>>>> >>>> _______________________________________________ >>>> WLUG mailing list -- wlug(a)lists.wlug.org >>>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>>> Change Settings: >>>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>>> Web Forum/Archive: >>>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/DM5K6… >>>> >>>

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jared Greenwald

Sorry I was more thinking of TruCluster. I know we have a lot of contacts in common from that time. On Thu, Feb 4, 2021, 3:30 PM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> wrote: > The port of Tru64 to Itanium must have been after I left. I do not know > anyone in the Tru64 product management that would have given any life to > that project. No life. None. > > I can ask one of the engineering managers of that time. > > md > > On Thu, Feb 4, 2021 at 2:13 PM Jared Greenwald <greenwaldjared(a)gmail.com> > wrote: > >> Still boggles my mind the amount of money HP spent on Itanium hardware >> back after they acquired Compaq/Tru64 only to basically abandon the whole >> thing and lay off everyone. >> >> On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall via WLUG < >> wlug(a)lists.wlug.org> wrote: >> >>> I still vividly remember my boss showing me the plans for support of >>> Intel's Itanium processor. >>> >>> As someone who taught operating systems and compiler design for a number >>> of years I still remember my shock that THIS was the answer for Intel's >>> 64-bit chip....an Ultra-Wide Instruction set. >>> >>> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly >>> because I had spent the past six months proving why even a regular CISC >>> system was the wrong answer, and here Intel was going in the opposite >>> direction. >>> >>> After twenty minutes of me fuming my boss simply grinned, shrugged his >>> shoulders and left my office. >>> >>> While I was proud of the fact that the Alpha processor was so prominent >>> in the production of the movie "Titanic"......now I had to deal with a real >>> life "Itanic"....watching it sink. >>> >>> md >>> >>> P.S. It was only a month or so after, I think, that AMD came out with a >>> reasonable extension to the i86 architecture....which (although it was not >>> RISC) I was reasonably happy with. >>> >>> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> >>> wrote: >>> >>>> Hey Everybody, >>>> >>>> We've got a meeting next week on the 11th at our same time (7pm) >>>> >>>> As for a topic, if somebody would like to present something, I'd be >>>> up for it. >>>> I figure we'd all toast the depreciation of Itanium in the linux >>>> kernel. Good riddance! >>>> >>>> We'll definitely be talking about the PI4 Nano!! >>>> >>>> As usual, I'm sure other topics will organically surface. >>>> >>>> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >>>> >>>> Later, >>>> Tim. >>>> -- >>>> I am leery of the allegiances of any politician who refers to their >>>> constituents as "consumers". >>>> _______________________________________________ >>>> WLUG mailing list -- wlug(a)lists.wlug.org >>>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>>> Change Settings: >>>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>>> Web Forum/Archive: >>>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >>>> >>> _______________________________________________ >>> WLUG mailing list -- wlug(a)lists.wlug.org >>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>> Change Settings: >>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>> Web Forum/Archive: >>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/DM5K6… >>> >>

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

The port of Tru64 to Itanium must have been after I left. I do not know anyone in the Tru64 product management that would have given any life to that project. No life. None. I can ask one of the engineering managers of that time. md On Thu, Feb 4, 2021 at 2:13 PM Jared Greenwald <greenwaldjared(a)gmail.com> wrote: > Still boggles my mind the amount of money HP spent on Itanium hardware > back after they acquired Compaq/Tru64 only to basically abandon the whole > thing and lay off everyone. > > On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall via WLUG < > wlug(a)lists.wlug.org> wrote: > >> I still vividly remember my boss showing me the plans for support of >> Intel's Itanium processor. >> >> As someone who taught operating systems and compiler design for a number >> of years I still remember my shock that THIS was the answer for Intel's >> 64-bit chip....an Ultra-Wide Instruction set. >> >> I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly >> because I had spent the past six months proving why even a regular CISC >> system was the wrong answer, and here Intel was going in the opposite >> direction. >> >> After twenty minutes of me fuming my boss simply grinned, shrugged his >> shoulders and left my office. >> >> While I was proud of the fact that the Alpha processor was so prominent >> in the production of the movie "Titanic"......now I had to deal with a real >> life "Itanic"....watching it sink. >> >> md >> >> P.S. It was only a month or so after, I think, that AMD came out with a >> reasonable extension to the i86 architecture....which (although it was not >> RISC) I was reasonably happy with. >> >> On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> >> wrote: >> >>> Hey Everybody, >>> >>> We've got a meeting next week on the 11th at our same time (7pm) >>> >>> As for a topic, if somebody would like to present something, I'd be >>> up for it. >>> I figure we'd all toast the depreciation of Itanium in the linux kernel. >>> Good riddance! >>> >>> We'll definitely be talking about the PI4 Nano!! >>> >>> As usual, I'm sure other topics will organically surface. >>> >>> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >>> >>> Later, >>> Tim. >>> -- >>> I am leery of the allegiances of any politician who refers to their >>> constituents as "consumers". >>> _______________________________________________ >>> WLUG mailing list -- wlug(a)lists.wlug.org >>> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >>> Create Account: https://wlug.mailman3.com/accounts/signup/ >>> Change Settings: >>> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >>> Web Forum/Archive: >>> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >>> >> _______________________________________________ >> WLUG mailing list -- wlug(a)lists.wlug.org >> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >> Create Account: https://wlug.mailman3.com/accounts/signup/ >> Change Settings: >> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >> Web Forum/Archive: >> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/DM5K6… >> >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jared Greenwald

Still boggles my mind the amount of money HP spent on Itanium hardware back after they acquired Compaq/Tru64 only to basically abandon the whole thing and lay off everyone. On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall via WLUG < wlug(a)lists.wlug.org> wrote: > I still vividly remember my boss showing me the plans for support of > Intel's Itanium processor. > > As someone who taught operating systems and compiler design for a number > of years I still remember my shock that THIS was the answer for Intel's > 64-bit chip....an Ultra-Wide Instruction set. > > I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly > because I had spent the past six months proving why even a regular CISC > system was the wrong answer, and here Intel was going in the opposite > direction. > > After twenty minutes of me fuming my boss simply grinned, shrugged his > shoulders and left my office. > > While I was proud of the fact that the Alpha processor was so prominent in > the production of the movie "Titanic"......now I had to deal with a real > life "Itanic"....watching it sink. > > md > > P.S. It was only a month or so after, I think, that AMD came out with a > reasonable extension to the i86 architecture....which (although it was not > RISC) I was reasonably happy with. > > On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> > wrote: > >> Hey Everybody, >> >> We've got a meeting next week on the 11th at our same time (7pm) >> >> As for a topic, if somebody would like to present something, I'd be >> up for it. >> I figure we'd all toast the depreciation of Itanium in the linux kernel. >> Good riddance! >> >> We'll definitely be talking about the PI4 Nano!! >> >> As usual, I'm sure other topics will organically surface. >> >> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >> >> Later, >> Tim. >> -- >> I am leery of the allegiances of any politician who refers to their >> constituents as "consumers". >> _______________________________________________ >> WLUG mailing list -- wlug(a)lists.wlug.org >> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >> Create Account: https://wlug.mailman3.com/accounts/signup/ >> Change Settings: >> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >> Web Forum/Archive: >> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >> > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/DM5K6… >

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Tim Keller

John, My perspective was from working at Stratus. Continuum at the time was our flagship line of servers that ran on PA-RISC and with Itanium it was clear the end of the line for PA-RISC was coming. Bob Evans and others who were more intimately involved can probably explain it better, but I remember Stratus getting a couple Itanium development workstations and my recollection was that the engineers weren't impressed. It wasn't a fundamental improvement on PA-RISC as far as they could tell. Ultimately VOS was ported to Xeon and the rest is history. I'm *sure* someone somewhere is still happily running PA-RISC based Stratus servers, but I have to imagine that number dwindles each year. Personally I have a hypothesis that Intel had really put it's bets on Xeon and wasn't really that invested in Itanium. What it did do was get HP out of the HPC market. It's fair to say that Xeon based systems running Linux pretty much put the coffin nails in MIPS, PA-RISC and ultimately Sparc and likely a few others I don't know about and with it the various operating systems that didn't get ported to Xeon. On Thu, Feb 4, 2021 at 11:44 AM Jon "maddog" Hall <jon.maddog.hall(a)gmail.com> wrote: > I still vividly remember my boss showing me the plans for support of > Intel's Itanium processor. > > As someone who taught operating systems and compiler design for a number > of years I still remember my shock that THIS was the answer for Intel's > 64-bit chip....an Ultra-Wide Instruction set. > > I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly > because I had spent the past six months proving why even a regular CISC > system was the wrong answer, and here Intel was going in the opposite > direction. > > After twenty minutes of me fuming my boss simply grinned, shrugged his > shoulders and left my office. > > While I was proud of the fact that the Alpha processor was so prominent in > the production of the movie "Titanic"......now I had to deal with a real > life "Itanic"....watching it sink. > > md > > P.S. It was only a month or so after, I think, that AMD came out with a > reasonable extension to the i86 architecture....which (although it was not > RISC) I was reasonably happy with. > > On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> > wrote: > >> Hey Everybody, >> >> We've got a meeting next week on the 11th at our same time (7pm) >> >> As for a topic, if somebody would like to present something, I'd be >> up for it. >> I figure we'd all toast the depreciation of Itanium in the linux kernel. >> Good riddance! >> >> We'll definitely be talking about the PI4 Nano!! >> >> As usual, I'm sure other topics will organically surface. >> >> Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA >> >> Later, >> Tim. >> -- >> I am leery of the allegiances of any politician who refers to their >> constituents as "consumers". >> _______________________________________________ >> WLUG mailing list -- wlug(a)lists.wlug.org >> To unsubscribe send an email to wlug-leave(a)lists.wlug.org >> Create Account: https://wlug.mailman3.com/accounts/signup/ >> Change Settings: >> https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ >> Web Forum/Archive: >> https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >> > -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 4, 2021

Re: WLUG Meeting Feb 11th 2021! Topic: Good question!

by Jon "maddog" Hall

I still vividly remember my boss showing me the plans for support of Intel's Itanium processor. As someone who taught operating systems and compiler design for a number of years I still remember my shock that THIS was the answer for Intel's 64-bit chip....an Ultra-Wide Instruction set. I wailed away about how all of this was WRONG, WRONG, WRONG.....mostly because I had spent the past six months proving why even a regular CISC system was the wrong answer, and here Intel was going in the opposite direction. After twenty minutes of me fuming my boss simply grinned, shrugged his shoulders and left my office. While I was proud of the fact that the Alpha processor was so prominent in the production of the movie "Titanic"......now I had to deal with a real life "Itanic"....watching it sink. md P.S. It was only a month or so after, I think, that AMD came out with a reasonable extension to the i86 architecture....which (although it was not RISC) I was reasonably happy with. On Thu, Feb 4, 2021 at 7:24 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> wrote: > Hey Everybody, > > We've got a meeting next week on the 11th at our same time (7pm) > > As for a topic, if somebody would like to present something, I'd be up for > it. > I figure we'd all toast the depreciation of Itanium in the linux kernel. > Good riddance! > > We'll definitely be talking about the PI4 Nano!! > > As usual, I'm sure other topics will organically surface. > > Location: Our usual Jitsu haunt: https://meet.jit.si/WlugMA > > Later, > Tim. > -- > I am leery of the allegiances of any politician who refers to their > constituents as "consumers". > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/BJNCC… >

Feb. 4, 2021