| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:28:07 |
| Calls: | 583 |
| Files: | 1,139 |
| D/L today: |
179 files (27,921K bytes) |
| Messages: | 111,799 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
The common Linux kernel shared across just about all distros supports
common standard filesystems. This is one reason why “distro-hopping” is >> a common thing among Linux users, while any attempt to pull such an
equivalent stunt between BSD variants is going to be fraught with
pitfalls.
How many of the people who would be "distro-hopping" re-use existing filesystems rather than re-installing completely from scratch?
How many of the people who would be "distro-hopping" re-use existing filesystems rather than re-installing completely from scratch?
I understand that you see a problem here, but I'm not sure that I do.
One example illustrating the difference in mindset, I think, is thatFreeBSD supports GPT and MBR too. IIRC it can also read various file
the Linux kernel can read any kind of disk partition format -- DOS,
Apple, whatever. Whereas the BSDs still want a disk to be formatted
according to their own system of “slices”.
On 04.09.2024 22:08 Uhr Lawrence D'Oliveiro wrote:
One example illustrating the difference in mindset, I think, is that
the Linux kernel can read any kind of disk partition format -- DOS,
Apple, whatever. Whereas the BSDs still want a disk to be formatted
according to their own system of “slices”.
FreeBSD supports GPT and MBR too. IIRC it can also read various file
systems using additional software fro the repo.
FreeBSD supports GPT and MBR too. IIRC it can also read various file
systems using additional software fro the repo.
On 14 Sep 2024 02:50:05 -0300, Mike Spencer wrote:
(I do now, at last, have a cell phone, hate the touchscreen GUI, don't
know how to do anything except phone calls, text and wireless access
point. Where are the manpages?)
A minute’s silence for the legendary Debian-based Nokia N9.
Development was well under way by the time Microsoft’s mole, Stephen Elop, came in and decreed that the company would bet its entire future on the laughable Windows Phone. So he couldn’t kill it completely, but he could ensure that the first of this product line was also the last. It got
limited release in a few countries, garnered rave reviews wherever it was available, sold out what stock was available, and that was the end of it.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 06:55:55 -0000 (UTC), Sebastian wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
?Unix-like? tends to mean ?Linux-like? these days, let?s face it. Linux >>>> leads, the other *nixes follow.
I hope not. Linux gets shittier with each turd that drops from the
FreeDesktop people.
Like I said, if you don?t like Linux distros infested with FreeDesktop-
isms, don?t use them. There?s no need to bring up all this bile: all it?s >> doing is aggravating your ulcers. Open Source is all about choice.
The choices are drying up. Increasingly, decisions are made by distros instead of users, and you only have a choice if there are any distros
left that haven't caved or collapsed, or if you have the time, money,
and charisma to create AND MAINTAIN a new distro. That used to not be necessary simply to have a choice. It used to be sufficient to install
a decent distro. The main distros used to let you have far more choice
than they do today.
Why do you hate the Free Desktop folks? They are at the forefront of
trying to modernize the *nix GUI.
The Linux GUI had no need of such modernization, especially since all
"modernization" really is, is Windowsization ...
Actually, it?s not. Linux GUIs very much go their own way; there are ones >> that copy Windows and even Apple, it is true, but that?s just to appeal to >> those who prefer that look.
Systemd copies Windows and Apple at a lower level, and it continues
to be forced on the Linux community from every direction. I don't
even think Devuan will be able to resist the pressure to run Systemd
for much longer. And every distro is adopting iproute2, the main
effect of which is to make Linux networking skills less transferrable
to BSD (basically vendor-lock).
There are others that go in quite different
directions. The customizability of KDE Plasma, for example, goes beyond
anything you?ll find in any proprietary platform.
And the beauty of Linux is, you can install any number of these GUI
environments at once, and switching between them is as easy as logging out >> and logging in again. You don?t even have to reboot.
Linux was more customizable in the past, and Wayland makes the problem
worse because there will always be only a few compositors, due to them
having to be so complicated. Plus, we are now seeing with the Hyprland
fiasco that distros will remove good compositors from their package management system if their managers perceive any of the authors of that compositor to have committed a thoughtcrime.
I used to run GNOME, and then GNOME 3 came out, and Debian released
it under the same package name, as if it was just the next version
of GNOME. What it actually was, was a turd to the face directly out
of the asses of the FreeDesktop-influenced GNOME developers. It was completely static, with no customizability at all. They promised to add customizability back later, but GNOME 3 was so intolerable, that I had
to find an alternative. ANY alternative. I tried KDE, but it had gotten
a shitty rewrite, just like GNOME, and had become just as intolerable
as GNOME. So I switched to XFCE for years, even though it was inferior
to GNOME and KDE as I previously knew them, until I finally noticed that
MATE was available on Debian (for now-- I assume it will get removed
at some point, or it will come to suck just as much as GNOME).
And the reasoning behind the GNOME rewrite was about as anti-user as
it's possible to be: The FreeDesktop faggots had decided that desktop
PCs were obsolete, and that we had to march towards the brave new
future, in which we'd trade our desktop machines for tablets and
fucking phones. Microsoft had the same idea, and released Windows 8
the following year, which had a bunch of stupid features that were specifically for mobile toys. They'd have taken our desktop computers
by force if they had the power to do so. They have more power today
than they did back then, so we might see a revival of the whole
"desktops are obsolete" idea in the next decade or so.
I saw GNOME 3 a couple of years ago on Ubuntu, and it still sucked,
but people still praise it for some fucked-up reason. I assume the same
thing is going on with KDE. I'm more likely to try CDE now that it's open-source, than KDE.
Just run WindowMaker with the OneStepBack or TwoStepsBack GTK2-4 themes
and the GNUstep icon theme for XDG.
Lxappearance will allow you to set your GTK theme/icons/fonts with ease
so it matches the WM one.
On Sat, 5 Jul 2025 21:35:14 +0200, Marco Moock wrote:
FreeBSD supports GPT and MBR too. IIRC it can also read various file systems using additional software fro the repo.
What about interchanging UFS volumes with other BSDs?
On Sun, 6 Jul 2025 06:08:14 -0000 (UTC), anthk wrote:
Just run WindowMaker with the OneStepBack or TwoStepsBack GTK2-4 themes
and the GNUstep icon theme for XDG.
Lxappearance will allow you to set your GTK theme/icons/fonts with ease
so it matches the WM one.
Also don’t forget the Mate and Cinnamon projects: Mate originated from GNOME/GTK 2, while Cinnamon is an offshoot from GNOME/GTK 3.
If you took it to a little endian machine all the bytes were the
wrong way around. This was because there was no model in which hard
drives would move between machines so they just dumped in-memory
structs to disc.
On 06 Jul 2025 12:43:29 +0100 (BST), Theo wrote:
If you took it to a little endian machine all the bytes were the
wrong way around. This was because there was no model in which hard
drives would move between machines so they just dumped in-memory
structs to disc.
But they had removable disk packs in those days. Also floppies, magneto- optical and optical media.
At Yale our PDP-11 originally had an RK05 single platter 1MB drive in
1974, then we upgraded to a pair of RP02 washing machine sized drives,
20MB each.
We also had a PDP-10 which also used the same RP02 disks. I think I
once experimented with trying to write a PDP-11 formatted disk on the
-10, reading the file system from tape. It was rather exciting since
the 36 bit PDP-10 mapped its words into the disk's 8 bit bytes in
non-obvious ways.
Removable disc packs mostly came later I think (although I wasn't aware
the 44MB Syquest launched as early as 1986). Optical media used
ISO9660; I'm not sure what was common for M-O drives.
According to Theo <theom+news@chiark.greenend.org.uk>:
Removable disc packs mostly came later I think (although I wasn't aware the >44MB Syquest launched as early as 1986). Optical media used ISO9660; I'm >not sure what was common for M-O drives.
Uh, what? Removable disk packs date from about 1960.
On 2024-08-27, Sebastian <sebastian@here.com.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 06:55:55 -0000 (UTC), Sebastian wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
?Unix-like? tends to mean ?Linux-like? these days, let?s face it. Linux >>>>> leads, the other *nixes follow.
I hope not. Linux gets shittier with each turd that drops from the
FreeDesktop people.
Like I said, if you don?t like Linux distros infested with FreeDesktop-
isms, don?t use them. There?s no need to bring up all this bile: all it?s >>> doing is aggravating your ulcers. Open Source is all about choice.
The choices are drying up. Increasingly, decisions are made by distros
instead of users, and you only have a choice if there are any distros
left that haven't caved or collapsed, or if you have the time, money,
and charisma to create AND MAINTAIN a new distro. That used to not be
necessary simply to have a choice. It used to be sufficient to install
a decent distro. The main distros used to let you have far more choice
than they do today.
Why do you hate the Free Desktop folks? They are at the forefront of >>>>> trying to modernize the *nix GUI.
The Linux GUI had no need of such modernization, especially since all
"modernization" really is, is Windowsization ...
Actually, it?s not. Linux GUIs very much go their own way; there are ones >>> that copy Windows and even Apple, it is true, but that?s just to appeal to >>> those who prefer that look.
Systemd copies Windows and Apple at a lower level, and it continues
to be forced on the Linux community from every direction. I don't
even think Devuan will be able to resist the pressure to run Systemd
for much longer. And every distro is adopting iproute2, the main
effect of which is to make Linux networking skills less transferrable
to BSD (basically vendor-lock).
There are others that go in quite different
directions. The customizability of KDE Plasma, for example, goes beyond >>> anything you?ll find in any proprietary platform.
And the beauty of Linux is, you can install any number of these GUI
environments at once, and switching between them is as easy as logging out >>> and logging in again. You don?t even have to reboot.
Linux was more customizable in the past, and Wayland makes the problem
worse because there will always be only a few compositors, due to them
having to be so complicated. Plus, we are now seeing with the Hyprland
fiasco that distros will remove good compositors from their package
management system if their managers perceive any of the authors of that
compositor to have committed a thoughtcrime.
I used to run GNOME, and then GNOME 3 came out, and Debian released
it under the same package name, as if it was just the next version
of GNOME. What it actually was, was a turd to the face directly out
of the asses of the FreeDesktop-influenced GNOME developers. It was
completely static, with no customizability at all. They promised to add
customizability back later, but GNOME 3 was so intolerable, that I had
to find an alternative. ANY alternative. I tried KDE, but it had gotten
a shitty rewrite, just like GNOME, and had become just as intolerable
as GNOME. So I switched to XFCE for years, even though it was inferior
to GNOME and KDE as I previously knew them, until I finally noticed that
MATE was available on Debian (for now-- I assume it will get removed
at some point, or it will come to suck just as much as GNOME).
And the reasoning behind the GNOME rewrite was about as anti-user as
it's possible to be: The FreeDesktop faggots had decided that desktop
PCs were obsolete, and that we had to march towards the brave new
future, in which we'd trade our desktop machines for tablets and
fucking phones. Microsoft had the same idea, and released Windows 8
the following year, which had a bunch of stupid features that were
specifically for mobile toys. They'd have taken our desktop computers
by force if they had the power to do so. They have more power today
than they did back then, so we might see a revival of the whole
"desktops are obsolete" idea in the next decade or so.
I saw GNOME 3 a couple of years ago on Ubuntu, and it still sucked,
but people still praise it for some fucked-up reason. I assume the same
thing is going on with KDE. I'm more likely to try CDE now that it's
open-source, than KDE.
Just run WindowMaker with the OneStepBack or TwoStepsBack
GTK2-4 themes and the GNUstep icon theme for XDG.
Lxappearance will allow you to set your GTK theme/icons/fonts
with ease so it matches the WM one.
Then use qtconfig to tell QT5 to use a GTK theme. THere's
a qgnomestyle or similarly called one.
John Levine <johnl@taugh.com> wrote:
According to Theo <theom+news@chiark.greenend.org.uk>:
Removable disc packs mostly came later I think (although I wasn't aware the >>> 44MB Syquest launched as early as 1986). Optical media used ISO9660; I'm >>> not sure what was common for M-O drives.
Uh, what? Removable disk packs date from about 1960.
The issue under discussion was taking a removable pack from one vendor and plugging it into a different vendor's machine in order to read the data stored there, which is when format standardisation became relevant. In
1960s were people moving discs from DEC to IBM, or distributing software on disc packs for multiple vendors?
Tape and optical were their own separate things with their own formats, but AFAIK sending a 'HDD' formatted drive as a distribution format across multiple vendors didn't properly take off until USB, with some niche usage for Syquests in the late 80s/early 90s (and then Zip/Jazz etc).
FAT was never an officially standardised format of course, but when the machines were running the same software it didn't matter, and so a 'PC formatted' FAT HDD (USB/memory card/...) became a de facto interchange standard that non-PC vendors also adopted, as FAT floppies had previously.
Theo
On 2025-07-06, anthk <anthk@openbsd.home> wrote:
On 2024-08-27, Sebastian <sebastian@here.com.invalid> wrote:Thanks for the two about TwoStepsBack. I quite like the OneStepBack aesthetic. The older widget style still appeals to me more.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 06:55:55 -0000 (UTC), Sebastian wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
?Unix-like? tends to mean ?Linux-like? these days, let?s face it.
Linux leads, the other *nixes follow.
I hope not. Linux gets shittier with each turd that drops from the
FreeDesktop people.
Like I said, if you don?t like Linux distros infested with
FreeDesktop- isms, don?t use them. There?s no need to bring up all
this bile: all it?s doing is aggravating your ulcers. Open Source is
all about choice.
The choices are drying up. Increasingly, decisions are made by distros
instead of users, and you only have a choice if there are any distros
left that haven't caved or collapsed, or if you have the time, money,
and charisma to create AND MAINTAIN a new distro. That used to not be
necessary simply to have a choice. It used to be sufficient to
install a decent distro. The main distros used to let you have far
more choice than they do today.
Why do you hate the Free Desktop folks? They are at the forefront
of trying to modernize the *nix GUI.
The Linux GUI had no need of such modernization, especially since
all "modernization" really is, is Windowsization ...
Actually, it?s not. Linux GUIs very much go their own way; there are
ones that copy Windows and even Apple, it is true, but that?s just to
appeal to those who prefer that look.
Systemd copies Windows and Apple at a lower level, and it continues to
be forced on the Linux community from every direction. I don't even
think Devuan will be able to resist the pressure to run Systemd for
much longer. And every distro is adopting iproute2, the main effect of
which is to make Linux networking skills less transferrable to BSD
(basically vendor-lock).
There are others that go in quite different directions. The
customizability of KDE Plasma, for example, goes beyond anything
you?ll find in any proprietary platform.
And the beauty of Linux is, you can install any number of these GUI
environments at once, and switching between them is as easy as
logging out and logging in again. You don?t even have to reboot.
Linux was more customizable in the past, and Wayland makes the problem
worse because there will always be only a few compositors, due to them
having to be so complicated. Plus, we are now seeing with the Hyprland
fiasco that distros will remove good compositors from their package
management system if their managers perceive any of the authors of
that compositor to have committed a thoughtcrime.
I used to run GNOME, and then GNOME 3 came out, and Debian released it
under the same package name, as if it was just the next version of
GNOME. What it actually was, was a turd to the face directly out of
the asses of the FreeDesktop-influenced GNOME developers. It was
completely static, with no customizability at all. They promised to
add customizability back later, but GNOME 3 was so intolerable, that I
had to find an alternative. ANY alternative. I tried KDE, but it had
gotten a shitty rewrite, just like GNOME, and had become just as
intolerable as GNOME. So I switched to XFCE for years, even though it
was inferior to GNOME and KDE as I previously knew them, until I
finally noticed that MATE was available on Debian (for now-- I assume
it will get removed at some point, or it will come to suck just as
much as GNOME).
And the reasoning behind the GNOME rewrite was about as anti-user as
it's possible to be: The FreeDesktop faggots had decided that desktop
PCs were obsolete, and that we had to march towards the brave new
future, in which we'd trade our desktop machines for tablets and
fucking phones. Microsoft had the same idea, and released Windows 8
the following year, which had a bunch of stupid features that were
specifically for mobile toys. They'd have taken our desktop computers
by force if they had the power to do so. They have more power today
than they did back then, so we might see a revival of the whole
"desktops are obsolete" idea in the next decade or so.
I saw GNOME 3 a couple of years ago on Ubuntu, and it still sucked,
but people still praise it for some fucked-up reason. I assume the
same thing is going on with KDE. I'm more likely to try CDE now that
it's open-source, than KDE.
Just run WindowMaker with the OneStepBack or TwoStepsBack GTK2-4 themes
and the GNUstep icon theme for XDG.
Lxappearance will allow you to set your GTK theme/icons/fonts with ease
so it matches the WM one.
Then use qtconfig to tell QT5 to use a GTK theme. THere's a qgnomestyle
or similarly called one.
On 06 Jul 2025 12:43:29 +0100 (BST), Theo wrote:
If you took it to a little endian machine all the bytes were the
wrong way around. This was because there was no model in which hard
drives would move between machines so they just dumped in-memory
structs to disc.
But they had removable disk packs in those days.
I'm not 100% sure but I think this company. hardly more than a footnote in >> computer history, was the cause of little-endian processors.
Guess again
Try the DEC PDP-11 (1969)
There was already a battle between bit 0 on the left or right in 1950s mainframes.
Which means it's IBM's fault.There was already a battle between bit 0 on the left or right in
1950s mainframes.
Endian-ness didnrCOt really matter before byte-addressability came
along, though.
...although bit ordering *can* make a difference in serial transmissionThere was already a battle between bit 0 on the left or right in
1950s mainframes.
Endian-ness didnrCOt really matter before byte-addressability came
along, though.
John Levine <johnl@taugh.com> wrote:
According to Theo <theom+news@chiark.greenend.org.uk>:
Removable disc packs mostly came later I think (although I wasn't aware the >> >44MB Syquest launched as early as 1986). Optical media used ISO9660; I'm >> >not sure what was common for M-O drives.
Uh, what? Removable disk packs date from about 1960.
The issue under discussion was taking a removable pack from one vendor and plugging it into a different vendor's machine in order to read the data stored there, which is when format standardisation became relevant. In
1960s were people moving discs from DEC to IBM, or distributing software on disc packs for multiple vendors?
Tape and optical were their own separate things with their own formats, but AFAIK sending a 'HDD' formatted drive as a distribution format across multiple vendors didn't properly take off until USB, with some niche usage for Syquests in the late 80s/early 90s (and then Zip/Jazz etc).
FAT was never an officially standardised format of course, but when the machines were running the same software it didn't matter, and so a 'PC formatted' FAT HDD (USB/memory card/...) became a de facto interchange standard that non-PC vendors also adopted, as FAT floppies had previously.
On Mon, 7 Jul 2025 04:22:52 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There was already a battle between bit 0 on the left or right in
1950s mainframes.
Endian-ness didnrCOt really matter before byte-addressability came
along, though.
Which means it's IBM's fault.
On Sun, 6 Jul 2025 20:15:08 -0700, Al Kossow wrote:
I'm not 100% sure but I think this company. hardly more than a footnote
in computer history, was the cause of little-endian processors.
Guess again
Try the DEC PDP-11 (1969)
There was already a battle between bit 0 on the left or right in 1950s
mainframes.
True, but that didn't lead to the 8008 which led to the...
https://en.wikipedia.org/wiki/Intel_8008
I should have been more explicit and said x64 processors. I've always been amused at how we got to where we are now.
Ironically Motorola certainly studied the PDP-11 closely but the 68000
wound up big-endian.
I never dug too deeply into the PDP-11 when I ran on one in the early
'80s. It was running some *nix OS that had fallen off the back of a truck
on Memorial Avenue.
John Levine <johnl@taugh.com> wrote:
According to Theo <theom+news@chiark.greenend.org.uk>:
Removable disc packs mostly came later I think (although I wasn't aware the >>> 44MB Syquest launched as early as 1986). Optical media used ISO9660; I'm >>> not sure what was common for M-O drives.
Uh, what? Removable disk packs date from about 1960.
The issue under discussion was taking a removable pack from one vendor and plugging it into a different vendor's machine in order to read the data stored there, which is when format standardisation became relevant. In
1960s were people moving discs from DEC to IBM, or distributing software on disc packs for multiple vendors?
Tape and optical were their own separate things with their own formats, but AFAIK sending a 'HDD' formatted drive as a distribution format across multiple vendors didn't properly take off until USB, with some niche usage for Syquests in the late 80s/early 90s (and then Zip/Jazz etc).
FAT was never an officially standardised format of course, but when the machines were running the same software it didn't matter, and so a 'PC formatted' FAT HDD (USB/memory card/...) became a de facto interchange standard that non-PC vendors also adopted, as FAT floppies had previously.
Theo
On Mon, 7 Jul 2025 04:22:52 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There was already a battle between bit 0 on the left or right in
1950s mainframes.
Endian-ness didnrCOt really matter before byte-addressability came
along, though.
...although bit ordering *can* make a difference in serial transmission (which end do you send first?) and bit-addressed instructions (where present.)
...although bit ordering *can* make a difference in serial
transmission (which end do you send first?) and bit-addressed
instructions (where present.)
This drove me nuts. I may have this wrong because it's 45+ years ago,
but I think BTAM received data LSB first, and I had to translate, or
else the documentation showed the characters LSB first, and I had to mentally translate all the doc.
Motorola studied the PDP-11 and fixed the things DEC got wrong. We'd be
in a different world if the 680x0 had won out over the x86.
Theo <theom+news@chiark.greenend.org.uk> wrote:
John Levine <johnl@taugh.com> wrote:
According to Theo <theom+news@chiark.greenend.org.uk>:
Removable disc packs mostly came later I think (although I wasn't aware the
44MB Syquest launched as early as 1986). Optical media used ISO9660; I'm >>> >not sure what was common for M-O drives.
Uh, what? Removable disk packs date from about 1960.
The issue under discussion was taking a removable pack from one vendor and >> plugging it into a different vendor's machine in order to read the data
stored there, which is when format standardisation became relevant. In
1960s were people moving discs from DEC to IBM, or distributing software on >> disc packs for multiple vendors?
Tape and optical were their own separate things with their own formats, but >> AFAIK sending a 'HDD' formatted drive as a distribution format across
multiple vendors didn't properly take off until USB, with some niche usage >> for Syquests in the late 80s/early 90s (and then Zip/Jazz etc).
Once Linux appeared I used it to ocasinaly read data from discs taken
from another machines like proprietary Unices. Yes, early HDD-s
used controller specific formatting so probably there were no chance
to read them on machine with different controller. But SCSI and
IDE discs could be swapped between widely different machines.
We also had a PDP-10 which also used the same RP02 disks. I think I
once experimented with trying to write a PDP-11 formatted disk on the
-10, reading the file system from tape. It was rather exciting since
the 36 bit PDP-10 mapped its words into the disk's 8 bit bytes in
non-obvious ways.
Its perfectly obvious, since the PDP-10 operating systems write 128 word blocks
at all times (even TOPS-20, which simply reads/writes 4 such blocks for each 512 word page in the data stream).
1 sector = 128 words * 36 bits = 64 * 72 bits = 576 * 8 bits
Easy-peasy.
Motorola studied the PDP-11 and fixed the things DEC got wrong.
Then there's the 'PDP-endian' quirk.
The issue under discussion was taking a removable pack from one vendor
and plugging it into a different vendor's machine in order to read the
data stored there ...
Endianness matter for character/digit addresable machines.
On 7/7/25 08:29, John Ames wrote:
This drove me nuts. I may have this wrong because it's 45+ years ago,
...although bit ordering *can* make a difference in serial transmission
(which end do you send first?) ...
but I think BTAM received data LSB first, and I had to translate, or
else the documentation showed the characters LSB first, and I had to
mentally translate all the doc.
I can understand endianness issues cropping up when you have to split a
word into independently-addressable chunks, but the fact that bit-
ordering was ever even a question remains bonkers to me, when basic math provides what *should've* been a straightforward universal standard: 2 ^
0 = 1, so bit 0 is the 1s place.
On Mon, 7 Jul 2025 09:55:21 -0700, Peter Flass wrote:
On 7/7/25 08:29, John Ames wrote:
This drove me nuts. I may have this wrong because it's 45+ years ago,
...although bit ordering *can* make a difference in serial
transmission (which end do you send first?) ...
but I think BTAM received data LSB first, and I had to translate, or
else the documentation showed the characters LSB first, and I had to
mentally translate all the doc.
The RS-232C spec explicitly said the least-significant bit was sent
first.
This drove me nuts. I may have this wrong because it's 45+ years ago,
but I think BTAM received data LSB first, and I had to translate, or
else the documentation showed the characters LSB first, and I had to
mentally translate all the doc.
John Levine <johnl@taugh.com> writes:
We also had a PDP-10 which also used the same RP02 disks. I think I
once experimented with trying to write a PDP-11 formatted disk on the
-10, reading the file system from tape. It was rather exciting since
the 36 bit PDP-10 mapped its words into the disk's 8 bit bytes in
non-obvious ways.
On 2025-07-07, Rich Alderson <news@alderson.users.panix.com> wrote:
Its perfectly obvious, since the PDP-10 operating systems write 128 word blocks
at all times (even TOPS-20, which simply reads/writes 4 such blocks for each >> 512 word page in the data stream).
1 sector = 128 words * 36 bits = 64 * 72 bits = 576 * 8 bits
Easy-peasy.
Just like the Univac/Unisys 1106/1108/1110/1100/2200, which read 9 8-bit >bytes (from disk or 9-track tape) into 2 36-bit words. Although I think
there was a way to put 8 bytes into quarter-words (9-bit bytes) instead.
On 07 Jul 2025 12:18:46 +0100 (BST), Theo wrote:
The issue under discussion was taking a removable pack from one vendor
and plugging it into a different vendor's machine in order to read the
data stored there ...
No, just moving packs between different machines in the same computer
centre would have been enough.
Unless you had an older Atari ST which formatted disk in such a way that >MSDOS wouldn't read them. I seem to remember it was one byte in the boot >sector the PC didn't like, and there were Atari programs to fix it...
Mon, 7 Jul 2025 13:43:32 +0100
David Wade <g4ugm@dave.invalid> schrieb:
[Schrieb]
Unless you had an older Atari ST which formatted disk in such a way that
MSDOS wouldn't read them. I seem to remember it was one byte in the boot
sector the PC didn't like, and there were Atari programs to fix it...
And there was at least one DOS-program.
ST2DOS, written by Arno Schaefer, version 1.0 is from '93.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On 07 Jul 2025 12:18:46 +0100 (BST), Theo wrote:
The issue under discussion was taking a removable pack from one vendor
and plugging it into a different vendor's machine in order to read the
data stored there ...
No, just moving packs between different machines in the same computer
centre would have been enough.
Until a fool operator (like you, perhaps) moved a pack from a drive
with a head crash to three other drives before realizing that the
pack was bad, not the drives.
You couldn't do a trick like that with the Amiga. It read and wrote an entire track at a time, which enabled it to shorten the inter-record
gaps to the point where it could store 11 sectors per track instead of
9.
This allowed the Amiga to store 880K on what was normally a 720K floppy
-
but the result could not be read except with another Amiga or a custom controller.
On Wed, 09 Jul 2025 04:29:09 GMT, Charlie Gibbs wrote:
You couldn't do a trick like that with the Amiga. It read and wrote an
entire track at a time, which enabled it to shorten the inter-record
gaps to the point where it could store 11 sectors per track instead of
9.
This allowed the Amiga to store 880K on what was normally a 720K floppy
-
but the result could not be read except with another Amiga or a custom
controller.
CP/M topped out for craziness. Most systems used the Western Digital
FD17xx floppy controllers but the controller could be programmed for different track/sector schemes and encoding. I had a utility that could
read 11 different formats iirc That's leaving out the hard sector types
that survived from the 8" days.
On 2025-07-08, Scott Lurndal <scott@slp53.sl.home> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On 07 Jul 2025 12:18:46 +0100 (BST), Theo wrote:
The issue under discussion was taking a removable pack from one vendor >>>> and plugging it into a different vendor's machine in order to read the >>>> data stored there ...
No, just moving packs between different machines in the same computer
centre would have been enough.
Until a fool operator (like you, perhaps) moved a pack from a drive
with a head crash to three other drives before realizing that the
pack was bad, not the drives.
But by then, the drives were bad too. :-(
CP/M topped out for craziness. Most systems used the Western Digital
FD17xx floppy controllers but the controller could be programmed for different track/sector schemes and encoding. I had a utility that could
read 11 different formats iirc That's leaving out the hard sector types that survived from the 8" days.
Then there was Apple. There were two schools of thought. Woz achieved a remarkably small parts count with an extremely creative way of utilizing
a floppy or he didn't know what the hell he was doing and reinvented the wheel, sort of. The end effect was nothing but an Apple could read Apple floppies.
DEC wasn't that naive when they tried to establish a captive audience for their specially formatted diskettes.
I stayed with 8-inch floppies on my CP/M box because their single-sided, single density (128-byte sectors, 250K per disk) could be read and
written by anything. The exception, as you mentioned, was hard-sectored disks - but let's not go there.
On Wed, 09 Jul 2025 22:30:17 GMT, Charlie Gibbs wrote:
I stayed with 8-inch floppies on my CP/M box because their single-sided,
single density (128-byte sectors, 250K per disk) could be read and
written by anything. The exception, as you mentioned, was hard-sectored
disks - but let's not go there.
The last thing I used that had 8" drives was this gem:
https://deramp.com/downloads/mostek/AID-80F/Mostek%20Restoration.pdf
I believe it used the STD bus which, despite the name, was anything but >standard. I even cooked up a bus and cards for Sprague Electric. They had
a severe case of NIH but they paid their invoices on time. Theirs not to >reason why...
Don't forget the ACT Sirius. A DOS machine, that crammed more data onto a >diskette buy using a variable speed drive (5 speeds, I think).
In article <md6n3pFgaflU8@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
Don't forget the ACT Sirius. A DOS machine, that crammed more data onto a >> diskette buy using a variable speed drive (5 speeds, I think).
Apple used the same trick with its 3.5" floppy drives to fit 800K onto a
disk that was only good for 720K elsewhere.
On 7/7/25 08:29, John Ames wrote:
On Mon, 7 Jul 2025 04:22:52 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
...although bit ordering *can* make a difference in serialThere was already a battle between bit 0 on the left or right in
1950s mainframes.
Endian-ness didnrCOt really matter before byte-addressability came
along, though.
transmission
(which end do you send first?) and bit-addressed instructions (where
present.)
This drove me nuts. I may have this wrong because it's 45+ years ago,
but I think BTAM received data LSB first, and I had to translate, or
else the documentation showed the characters LSB first, and I had to
mentally translate all the doc.
Also, lower case letter shapes are more complicated, so upper case
is more robust to low quality print ...
ASCII not, what your machine can do for you. -- IBM
Aye, I really like the internal 400k floppy on my 128k Mac because
you can hear the drive speeding up and slowing down depending on
which region is being read.
On Fri, 18 Jul 2025 23:23:12 GMT, Charlie Gibbs wrote:
ASCII not, what your machine can do for you. -- IBM
... rCLASCII what you can do for your machinerCY.
Sums up IBM equipment (and software) in a nutshell.
Did the 3178 come with an APL feature?On a real 3178 there are no [] characters so you either lose some
other characters, or use tri-graphs.
Not unless you paid a lot of money. In those times every mod was an
expensive extra, even if it was a link of wire..
Real terminals went away pretty quickly.
The project I was on was using emulators except for some of us with
3290s.
I think you were late on the scene. I started on 2260's which date
from 1964. The IBM PC wasn't released until 1981, some 17 years
later. 3270 emulation didn't happen until I think a couple of years
later, so almost 20 years after the first terminals. Yes they quickly replaced terminals once they were available, but they were around for
a long time...
Dan Espen <dan1espen@gmail.com> wrote:
Lynn Wheeler <lynn@garlic.com> writes:
other trivia: account about biggest computer "goof" ever, 360s
originally were going to be ASCII machines, but the ASCII unit record
gear weren't ready ... so were going to start shipping with old BCD gear >>> (with EBCDIC) and move later
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
I don't know what dreams they were having within IBM but those machines
were never going to be ASCII. It would be pretty hard to do 14xx
emulation with ASCII and IBM NEVER EVER did a competent ASCII - EBCDIC
translate table.
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of
ASCII peripherials. But normal 1401 memory size were decimal, so
lower than corresponding binary numbers. And actual core had extra
space for use by microcode. So it does not look like a big problem.
On Fri, 18 Jul 2025 18:23:23 +0000, Waldek Hebisch wrote:
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of ASCII
peripherials. But normal 1401 memory size were decimal, so lower than
corresponding binary numbers. And actual core had extra space for use
by microcode. So it does not look like a big problem.
I worked on a mainframe that supported both ASCII and EBCDIC. There was a mode bit which selected which it would use.
The difference was conversion from decimal nibbles to normal bytes, in
that different zone bits were used.
Bob Eager <news0009@eager.cx> writes:
On Fri, 18 Jul 2025 18:23:23 +0000, Waldek Hebisch wrote:
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of ASCII
peripherials. But normal 1401 memory size were decimal, so lower than
corresponding binary numbers. And actual core had extra space for use
by microcode. So it does not look like a big problem.
I worked on a mainframe that supported both ASCII and EBCDIC. There was a
mode bit which selected which it would use.
The difference was conversion from decimal nibbles to normal bytes, in
that different zone bits were used.
Every 360 had a ASCII bit. That bit took quite a while to disappear
from the PSW. Never saw anyone attempt to turn it on.
Bob Eager <news0009@eager.cx> writes:
On Fri, 18 Jul 2025 18:23:23 +0000, Waldek Hebisch wrote:
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of ASCII
peripherials. But normal 1401 memory size were decimal, so lower than
corresponding binary numbers. And actual core had extra space for use
by microcode. So it does not look like a big problem.
I worked on a mainframe that supported both ASCII and EBCDIC. There was
a mode bit which selected which it would use.
The difference was conversion from decimal nibbles to normal bytes, in
that different zone bits were used.
Every 360 had a ASCII bit. That bit took quite a while to disappear
from the PSW. Never saw anyone attempt to turn it on.
antispam@fricas.org (Waldek Hebisch) writes:
Dan Espen <dan1espen@gmail.com> wrote:
Lynn Wheeler <lynn@garlic.com> writes:
other trivia: account about biggest computer "goof" ever, 360s
originally were going to be ASCII machines, but the ASCII unit record
gear weren't ready ... so were going to start shipping with old BCD gear >>>> (with EBCDIC) and move later
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
I don't know what dreams they were having within IBM but those machines
were never going to be ASCII. It would be pretty hard to do 14xx
emulation with ASCII and IBM NEVER EVER did a competent ASCII - EBCDIC
translate table.
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of
ASCII peripherials. But normal 1401 memory size were decimal, so
lower than corresponding binary numbers. And actual core had extra
space for use by microcode. So it does not look like a big problem.
Can't make much sense of the above.
14xx programs in emulation, by definition had to use BCD.
ASCII had a different collating sequence. It's not a translation issue.
On 7/19/25 12:28, Dan Espen wrote:
Bob Eager <news0009@eager.cx> writes:
On Fri, 18 Jul 2025 18:23:23 +0000, Waldek Hebisch wrote:
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables >>>> on output and input. This could require extra space in case of ASCII
peripherials. But normal 1401 memory size were decimal, so lower than >>>> corresponding binary numbers. And actual core had extra space for use >>>> by microcode. So it does not look like a big problem.
I worked on a mainframe that supported both ASCII and EBCDIC. There was a >>> mode bit which selected which it would use.
The difference was conversion from decimal nibbles to normal bytes, in
that different zone bits were used.
Every 360 had a ASCII bit. That bit took quite a while to disappear
from the PSW. Never saw anyone attempt to turn it on.
It never did anything. Its only defined effect was to change the signs >generated for packed-decimal data. I don't know what IBM was thinking.
David Wade <g4ugm@dave.invalid> writes:
Did the 3178 come with an APL feature?On a real 3178 there are no [] characters so you either lose some
other characters, or use tri-graphs.
Not unless you paid a lot of money. In those times every mod was an expensive extra, even if it was a link of wire..
Real terminals went away pretty quickly.
The project I was on was using emulators except for some of us with
3290s.
I think you were late on the scene. I started on 2260's which date
from 1964. The IBM PC wasn't released until 1981, some 17 years
later. 3270 emulation didn't happen until I think a couple of years
later, so almost 20 years after the first terminals. Yes they quickly replaced terminals once they were available, but they were around for
a long time...
Me, late on the scene?
I started programming in 1964 on IBM 14xx in Autocoder.
Did my first 2260 project using BTAM and assembler in 1968.
One of my favorite 327xs were the 3279 color terminals. Great keyboards
on those things. Looking back there was the punched card era, the 3270
era, then the 327x emulator era. I think I put in more years in
emulator era than the real terminal era.
----
Dan Espen
antispam@fricas.org (Waldek Hebisch) writes:
Dan Espen <dan1espen@gmail.com> wrote:
Lynn Wheeler <lynn@garlic.com> writes:
other trivia: account about biggest computer "goof" ever, 360s
originally were going to be ASCII machines, but the ASCII unit record
gear weren't ready ... so were going to start shipping with old BCD gear >>>> (with EBCDIC) and move later
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
I don't know what dreams they were having within IBM but those machines
were never going to be ASCII. It would be pretty hard to do 14xx
emulation with ASCII and IBM NEVER EVER did a competent ASCII - EBCDIC
translate table.
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of
ASCII peripherials. But normal 1401 memory size were decimal, so
lower than corresponding binary numbers. And actual core had extra
space for use by microcode. So it does not look like a big problem.
Can't make much sense of the above.
14xx programs in emulation, by definition had to use BCD.
ASCII had a different collating sequence. It's not a translation issue.
On Sat, 19 Jul 2025 15:16:03 -0400
Dan Espen <dan1espen@gmail.com> wrote:
David Wade <g4ugm@dave.invalid> writes:
Did the 3178 come with an APL feature?On a real 3178 there are no [] characters so you either lose some
other characters, or use tri-graphs.
Not unless you paid a lot of money. In those times every mod was an
expensive extra, even if it was a link of wire..
Real terminals went away pretty quickly.
The project I was on was using emulators except for some of us with
3290s.
I think you were late on the scene. I started on 2260's which date
from 1964. The IBM PC wasn't released until 1981, some 17 years
later. 3270 emulation didn't happen until I think a couple of years
later, so almost 20 years after the first terminals. Yes they quickly
replaced terminals once they were available, but they were around for
a long time...
Me, late on the scene?
I started programming in 1964 on IBM 14xx in Autocoder.
Did my first 2260 project using BTAM and assembler in 1968.
One of my favorite 327xs were the 3279 color terminals. Great keyboards
on those things. Looking back there was the punched card era, the 3270
era, then the 327x emulator era. I think I put in more years in
emulator era than the real terminal era.
Yeahbut I'd have to book the colour terminal way in advance - anyhow
green on black is more restful to the eyes. I missed out on autocoder,
being a mere stripling.
Dan Espen <dan1espen@gmail.com> wrote:
antispam@fricas.org (Waldek Hebisch) writes:
Dan Espen <dan1espen@gmail.com> wrote:
Lynn Wheeler <lynn@garlic.com> writes:
other trivia: account about biggest computer "goof" ever, 360s
originally were going to be ASCII machines, but the ASCII unit record >>>>> gear weren't ready ... so were going to start shipping with old BCD gear >>>>> (with EBCDIC) and move later
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
I don't know what dreams they were having within IBM but those machines >>>> were never going to be ASCII. It would be pretty hard to do 14xx
emulation with ASCII and IBM NEVER EVER did a competent ASCII - EBCDIC >>>> translate table.
Emulation would work without any change, CPU and almost all microcode
would be the same. IIUC what would differ would be translation tables
on output and input. This could require extra space in case of
ASCII peripherials. But normal 1401 memory size were decimal, so
lower than corresponding binary numbers. And actual core had extra
space for use by microcode. So it does not look like a big problem.
Can't make much sense of the above.
14xx programs in emulation, by definition had to use BCD.
Yes. And using ASCII in 360 OS-es have nothing to do with the
above.
ASCII had a different collating sequence. It's not a translation issue.
Internally emulator works in BCD. The only problem is to correctly
emulate I/O when working with ASCII periperials. That is solved
by using translation table (so that BCD code from emulator gives
correct glyph on the printer, etc).
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
On Sat, 19 Jul 2025 15:16:03 -0400
Dan Espen <dan1espen@gmail.com> wrote:
David Wade <g4ugm@dave.invalid> writes:
Did the 3178 come with an APL feature?On a real 3178 there are no [] characters so you either lose some
other characters, or use tri-graphs.
Not unless you paid a lot of money. In those times every mod was an
expensive extra, even if it was a link of wire..
Real terminals went away pretty quickly.
The project I was on was using emulators except for some of us with
3290s.
I think you were late on the scene. I started on 2260's which date
from 1964. The IBM PC wasn't released until 1981, some 17 years
later. 3270 emulation didn't happen until I think a couple of years
later, so almost 20 years after the first terminals. Yes they quickly
replaced terminals once they were available, but they were around for
a long time...
Me, late on the scene?
I started programming in 1964 on IBM 14xx in Autocoder.
Did my first 2260 project using BTAM and assembler in 1968.
One of my favorite 327xs were the 3279 color terminals. Great keyboards >> on those things. Looking back there was the punched card era, the 3270
era, then the 327x emulator era. I think I put in more years in
emulator era than the real terminal era.
Yeahbut I'd have to book the colour terminal way in advance - anyhow
green on black is more restful to the eyes. I missed out on autocoder, being a mere stripling.
One of my more favorite pastimes was redoing IBMs default 4-color color scheme of their ISPF screens. A 3279 was a 7 color terminal with
reverse image, underlining. It's amazing how much better you can make
a screen look with a little artistic skill.
At Bell Labs I had the 3279 on my desk for a year or so.
A short-term works colleague who was planning on doing-up^wrebuilding a cottage in mid-Wales for the quiet country life translated the ISPF
panels into Welsh.
Dan Espen <dan1espen@gmail.com> wrote:
antispam@fricas.org (Waldek Hebisch) writes:
Dan Espen <dan1espen@gmail.com> wrote:
antispam@fricas.org (Waldek Hebisch) writes:
Dan Espen <dan1espen@gmail.com> wrote:
Lynn Wheeler <lynn@garlic.com> writes:
other trivia: account about biggest computer "goof" ever, 360s
originally were going to be ASCII machines, but the ASCII unit record >>>>>>> gear weren't ready ... so were going to start shipping with old BCD gear
(with EBCDIC) and move later
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
I don't know what dreams they were having within IBM but those machines >>>>>> were never going to be ASCII. It would be pretty hard to do 14xx
emulation with ASCII and IBM NEVER EVER did a competent ASCII - EBCDIC >>>>>> translate table.
Emulation would work without any change, CPU and almost all microcode >>>>> would be the same. IIUC what would differ would be translation tables >>>>> on output and input. This could require extra space in case of
ASCII peripherials. But normal 1401 memory size were decimal, so
lower than corresponding binary numbers. And actual core had extra
space for use by microcode. So it does not look like a big problem.
Can't make much sense of the above.
14xx programs in emulation, by definition had to use BCD.
Yes. And using ASCII in 360 OS-es have nothing to do with the
above.
ASCII had a different collating sequence. It's not a translation issue. >>>Internally emulator works in BCD. The only problem is to correctly
emulate I/O when working with ASCII periperials. That is solved
by using translation table (so that BCD code from emulator gives
correct glyph on the printer, etc).
If printing is all your app does.
Cards are Hollerith. A close cousin of BCD.
The app would expect any card master file to to in BCD order.
Yes, card reader and card punch also need translation table.
That why I wrote etc above.
Tapes and disk have the same issue.
That is less clear: 1401 discs and tapes stored word marks which
made them incompatible with ususal 360 formats.
And discs were
ususally read on system of the same type. So extra translation
program (needed anyway due to word marks) could also handle change
of character codes when transfering data between system.
Clearly 1401 compatibility did not prevent introduction of CKD
discs. And CKD means different on disk format than 1401 disc.
On Mon, 21 Jul 2025 09:26:43 +0100, Kerr-Mudd, John wrote:
A short-term works colleague who was planning on doing-up^wrebuilding a cottage in mid-Wales for the quiet country life translated the ISPF
panels into Welsh.
For some reason, former Linux kernel developer Alan Cox immediately came
to mind ...