Re: DECStation 3100 on a RPi2040...
by Jon "maddog" Hall
Kevin,
I found two articles that gave more technical information on the exact
problem. First of all is this issue of the chip that was used to supply
"serial control" of various devices. Many people might not think about
it, but the keyboard and mice are also "serial devices" and used up two
ports of the four port DC7085 gate array:
These systems have four asynchronous serial lines that are provided by a
> DC7085 gate array. Of the four serial lines, only the third line has the
> required modem control signals to support a modem. A 4-pin MMJ connector is
> provided for the keyboard line, a 7-pin DIN connector for mouse line, and
> two 6-pin MMJ connectors for printer and modem lines.
>
> Now we put in who articles about what lines and pins were actually
implemented:
http://www.vanade.com/~blc/DS3100/pinouts.html
https://www.tuhs.org/Usenet/comp.unix.ultrix/1991-May/005327.html
Now it appears as if the DS 3000 had two "serial ports", one designated for
a modem and one designated for a printer. Reading them brings back more
of the "issues".
One issue is that many Unix systems were not used just as a desktop system,
but as "servers" too. A prime example of this was that a VMS Workstation
was only allowed a single user to be logged on at one time. A multi-user
license was not allowed for VMS Workstations through a dictum put forward
by VAX product management.
This, of course, was not what Unix people (and particularly Sun customers)
would do. They might have a single person using the keyboard, mouse and
main screen, but have several others logged onto the system over TCP/IP.
*You can now skip ahead to more about the issue of serial ports, but you
will be missing an interesting part of DEC history:*
For years DEC refused to sell a multi-user license to workstation users.
We even had a separate product called Ultrix-32w which was both the
Ultrix-32 software plus the graphical server and came with a two user
license (so either uucp or the network administrator) could log in at the
same time as the user at the main keyboard. However, no other general
user could log in at the same time. So the base Ultrix-32w came with that
two-user license, and there was no "upgrade".
Eventually I found this "rule" so damaging to Digital's Unix business that
I decided to fight it. This "rule" might have made sense in the original
days of 1 million instructions/second CPUs and unaccelerated graphics, but
made NO sense with the much faster and accelerated graphics. We were
being whipped senseless by Sun's marketing team.
So I traded this "rule" down, and finally found that it had been generated
by Jesse Lipcon, at that time a VP of workstations. I called him up and
explained the situation. "Oh, I NEVER meant that to apply to UNIX
Workstations...only VMS Workstations" said Jesse. "The Unix market is
much different."
So I held a meeting the next week. I picked the largest meeting room,
expecting there would be much argument. I made a huge presentation about
the whole issue and how much business we were missing. I pointed out that
it was really up to the customer how many people or processes would be on
that system, and DEC should not be limiting it artificially.
The day of the meeting, the room was packed. There were people standing
in the hallways.
I stood up at the front, made the presentation, and asked if anyone had
objections. No one raised their hand.
"Then why are you here?" I asked.
"We just came to see the fireworks." was the answer.
"Then Digital now sells multi-user workstations." I declared.
Of course things were a little more complicated than that, since there were
changes to documentation, licensing, and a whole project around adding
another graphics tube, keyboard and mouse to the hardware (the "Multi-User
Caylith" project), but we charged ahead with the multi-user system.
*Back to the serial ports:*
So the VMS viewpoint of workstations you *might* have a printer and a modem
hooked to the workstation, but more likely these would be attached to a
server someplace to be shared with other workstation users.
From a Unix standpoint, your workstation might ALSO be a server, and might
have a printer and modem OR TWO MODEMS attached to the workstation,
On either serial port they worked fairly well at lower transfer speeds with
handshaking, but with higher speeds the handshaking tended to break down,
especially if you hooked a second modem up to the "printer port".
Another issue was the lack of the "CD" line, that tells the system the
modem has lost connection, and requires that the software on the system
recognize this through a timeout.
This violated the concept of "DECstandard 052", a standard that was
developed for modems hooked up to DEC's systems. Before the adoption of
"DECstandard 052" in order to hook a modem up to a computer and a country's
telephone lines you had to test every modem with every piece of hardware
and every operating system in every country. This was not only a very
expensive process, but took a long time after operating system releases.
By developing DECstandard 052 the company made this a lot easier. The
hardware and operating system groups only had to certify against
DECstandard 052, and customers could then connect up any "standard" modems
and know that they had the modem control signals to reliably interact with
the modems of the country.
The DECstation 3100 did not meet DECstandard 052:
DEC STD 052-0 Operational Requirements for Serial Terminals and Computer
Interfaces Operating as DTEs Connected to EIA RS-232-C or CCITT V.28 Modems
- Part: EL-00052-00 - 1981
We've run both UUCP and SLIP on 3100s here; the modem-control "problems"
> really aren't that serious a problem unless you are a high-security sort of
> place. What is missing is the CD line that lets the modem tell the computer
> that it has lost its connection. This means that when the other end (or the
> phone company ;-) decides to hang up on you, the modem knows about it right
> away, but the software has to use a timeout mechanism, because the modem's
> attempt to say "Hey, we just lost the connection" does not get through.
>
> This allowed another call to arrive at the same port, and perhaps gain
control of it without having to authenticate.
Unlikely? Yes. Impossible? No.
Using the printer port for a modem made the issue even worse. After all,
you did not expect the printer to talk back to you at high speed.
So now you know the REST of the story.
md
On Sun, Jul 7, 2024 at 1:32 PM Kevin Stratton <kstratton(a)fastmail.us> wrote:
> I found this information interesting.
>
> The statement
>
> "To save a couple of pennies per system the
> > VAX hardware designers determined that having full hardware modem
> > control (DECstandard 52) on the board was not needed, because "very
> > few workstation users hook a modem up to their serial line".
>
> has two different meanings (to me) in the context of this discussion. They
> are:
>
> 1) RI and DCD are not implemented in hardware (Ring indicator and data
> carrier detect)
>
> 2) A subset of RTS, CTS, DSR, DTR as well as RI and DCD are not
> implemented in hardware.
>
> Does anyone want to clarify this in greater detail? Just curious.
>
>
> On 7/6/2024 8:59 PM, Jon "maddog" Hall via WLUG wrote:
>
> John:
>
> That's an interesting statement. I would think it was the same case
> and port setup, but a different motherboard since you couldn't just
> slot a MIPS processor into a VAXstation processor.
>
>
> That is why I said "based". "Based" means that you did not have to
> requalify a lot of the parts, that you could use a lot of the same Bill of
> Materials....it does not mean you use exactly the same PCB. In the case
> of the VAXstation/DECstation 3100 that meant we used the same serial io
> chips and did not provide the hardware flow control.
>
> Yes! It's coming back to me, the 3100s were horrible for serial,
>> though I think they had fixed it for the 5000 series systems, since
>> the DECstation 5000 and the DECserver 5100 were identical, except the
>> DECStation had a graphics card and cost 10-20% _less_ than the
>> DECstation 5000. So we bought DECStations and used them as servers.
>
>
> The server groups were different engineers, and the 5000s were designed
> after the DECstation 3100/2100 series.
>
> Actually we MIGHT have caught the issue with the serial port for the
> DECstation 3100/2100 because I brought up the issue in a hardware meeting
> and was assured that it had been fixed because (and I can still hear this
> person's voice in my head) the DECstation was a REAL UNIX MACHINE. I
> should have found that person later and beaten him to death.
>
> David:
>
>> Actually, Cutler was already in trouble with management because of the
>> Prism project. Prism was the first try at building a RISC machine (this
>> was in the 1985-1986 time frame) and it was managed by Dave Cutler.
>> Unfortunately, Dave was not a good administrator. He was doing a very bad
>> job of managing the project and doing a very bad job of keeping management
>> up to date on what was going on. Finally, management cancelled Prism and
>> that is when they decided to go with the MIPS architecture.
>>
>> That is not what I experienced. I will not comment on Dave's skills as
> an administrator or manager of the project. I do know that he had the
> very ambitious project of doing the next-generation architecture and the
> next generation operating system. He wanted a micro-kernel based system
> with "personalities", one personality being VMS and the other personality
> being Unix. One issue he had was when there was a clash between
> personalities he would always favor VMS and therefore the Unix personality
> would not be "perfect". I felt this was a mistake, since Unix people did
> not tolerate things that did not smell like Unix. VMS people could have
> been led over to a new environment over time since DEC controlled the path
> with VMS.
>
> The reason I know this is that I personally interviewed with David Cutler
> for the position of Unix Product Manager for his new operating system.
> The interview was going fine until I tried to explain to Dave why his
> strategy was wrong and he had to make the Unix side really compatible.
> Then things got ugly, as David really did not like to be told he was wrong.
>
> Ken did have the bad habit of cutting off Dave's development money, then
> giving it back to him again. I seem to remember that Dave was still going
> full steam ahead while the PMAX was being developed, which is one reason
> why he was caught so flat-footed when PMAX was announced. It was kept
> REALLY SECRET. It probably did not help that Ken reportedly asked David
> in a gleeful tone if the new chip would be as fast as the PMAX....
>
> "Will it be THIS FAST, Dave?" was the reported question.
>
> It is also my belief that the Alpha chip came directly from Dave's work on
> the PRISM, and that Windows NT came directly from David's work on the
> microkernel with personalities. DEC never "decided to go with MIPS"
> except as a stop-gap measure for Unix. If DEC had "decided to go with
> MIPS" they would have ported VMS to it, and since that never happened, it
> was obvious that DEC had not embraced MIPS.
>
> md
>
>
> On Sat, Jul 6, 2024 at 3:27 PM John Stoffel <john(a)stoffel.org> wrote:
>
>> >>>>> "Jon" == Jon \"maddog\" Hall via WLUG <wlug(a)lists.wlug.org> writes:
>>
>> > The DECstation 3100 (aka the PMAX) was a system based on the same
>> > motherboard as the VAXstation 3100, except with a MIPS processor.
>> > It was the first time that Digital had built a system using another
>> > company's chip architecture.
>>
>> That's an interesting statement. I would think it was the same case
>> and port setup, but a different motherboard since you couldn't just
>> slot a MIPS processor into a VAXstation processor.
>>
>> > We had a choice between supporting the MIPS R2000 chip as "big
>> > endian" or "little endian". We chose to support "little endian" to
>> > be compatible with PDP-11s, VAXen and Intel chips, rather than be
>> > compatible with other manufacturers. This, in my mind, was very
>> > important since it let us share data over NFS and give greater
>> > compatibility with programs and libraries of applications already
>> > running on other Unix-like systems such as Ultrix, BSD, etc. Sun
>> > experienced this grief when they ported Solaris off the big endian
>> > Motorola and SPARC chips to little endian Intel.
>>
>> > One of the few issues of the DECstation 3100 (and 2100, known as the
>> > "PMIN" after that) was that the serial I/O port did not support
>> > hardware handshaking. To save a couple of pennies per system the
>> > VAX hardware designers determined that having full hardware modem
>> > control (DECstandard 52) on the board was not needed, because "very
>> > few workstation users hook a modem up to their serial line". What
>> > they meant was that "very few VMS workstation users hooked a modem
>> > up to their serial line", opting for DECnet to handle their
>> > networking. Therefore the pins necessary to support hardware modem
>> > control were missing from the DECstation product lines.
>>
>> Yes! It's coming back to me, the 3100s were horrible for serial,
>> though I think they had fixed it for the 5000 series systems, since
>> the DECstation 5000 and the DECserver 5100 were identical, except the
>> DECStation had a graphics card and cost 10-20% _less_ than the
>> DECstation 5000. So we bought DECStations and used them as servers.
>> :-)
>>
>> I used to live and breathe the DEC options catalog, which was
>> something like an inch thick book in purple (maybe blue? maybe changed
>> each year?) with all the various options and configurations you could
>> get.
>>
>> > Unix users, on the other hand, often had modems hooked up to their
>> > workstation, to handle cu(1), uucp(1) and other serial line
>> > protocols. We eventually got around this by better refining
>> > software modem control, but it was painful.
>>
>> The EE department had Sun 1s at WPI, and they have the 9600 baud
>> bitnet connection running of a VAX 11/780 at the time.
>>
>> > The proposal, design and release of the DECstation 3100 was a
>> > top-secret project inside of DEC, kept secret from even many people
>> > in the Digital Unix group in Nashua, New Hampshire. The
>> > development of the system was done in Palo Alto's WorkStation
>> > Engineering group and the software engineering was done in the
>> > Western Software Labs in Palo Alto, albeit by taking key engineers
>> > from the Nashua facility and transplanting them temporarily to Palo
>> > Alto.
>>
>> > The implementation was kept so secret that it caught Dave Cutler,
>> > then working on DEC's next-generation operating system and chips, by
>> > surprise when it debuted at a Board Meeting in Maynard,
>> > Massachusetts. Shortly after that board meeting Mr. Cutler left
>> > Digital and moved (with some of his team) to Microsoft.
>>
>> Do you think that was just the straw that broke the camel's back?
>>
>> > The DECstations only were manufactured for a couple of years, as the
>> > DEC Alpha processor replaced MIPS in Digital's lineup. Although
>> > originally promised that OSF/1 would be ported to the DECstation
>> > line, this port was dropped due to realizing that there would never
>> > be an application base to support the customers of a DECstation
>> > OSF/1 port. It was better for ISVs and customers to maintain the
>> > Ultrix base for the DECstations than to split the base into Ultrix
>> > and OSF/1.
>>
>> Yeah, we had a ton of DECstations and a bunch of various early model
>> Alphas at WPI which we beta tested for DEC. The AS2100 with 8 DEC
>> StorageWorks canisters (which Netapp used on their early F220, F330,
>> F740 NAS systems) holding 3.5" disks, dual ported, hot-swapable. Nice
>> gear.
>>
>> The move from Ultrix to DEC OSF/1 was a bit painful, but not terrible
>> as I recall, but I'm sure I've blocked all the bad memories from then.
>>
>> Thanks for the walk down memory lane!
>> John
>>
>
> _______________________________________________
> 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/UUCPQ…
>
>
1 year, 3 months
looking forward to the 15th!
by Wes Allen
Hi gang,
I'm looking forward to the 15th of January so I can finally say good-bye to
Brother Bill on my iPAQ. I got a couple of questions.....
Has anyone used the perl-script that syncs the ipaq and evolution? Other
then the notorious, "Don't run this while Evolution is open" are there any
other problems?
Which CF wireless nics work with linux on the iPAQ. I'm seriously thinking
that I'm going to get the cf-plus expansion pack and a wireless nic for my
iPAQ (linux's true strength is networking, right?). So which one's work?
And, sadly, how easy is it to reverse the process? On the off-chance that I
can't stand OPIE as a working environment. I've read the howto, how hard is
it in "real life."
It might be fun to invite some of the people from the compaq lab to the
meeting if anyone who worked on ipaq linux is based in the Worcester area....
Wes
--
------
This message may be signed using GPG, for my public key please
send me a message with "Key Request" in the subject line.
22 years, 9 months
Re: [Wlug] Test needed on declared-ill Modem. Who has a lab?
by E Johnson
PS: This evening, Ch4rter Billing has deleted the upcoming service charge
for this morning's tech call. Amazing how it took 2 guys to check line
levels, then hang one moden where my other modem was, + plug in one coax &
one wall wart , then make 30-sec call to the office to get their repacement
modem provisioned & watch for blinking green lights. 2 guys.
If this happens to you (they discontinued your router & required you to use
theirs), don't eat the bill.
it does work fine, FWIW, but not impressed.
--EJ
On 20 September 2012 19:11, E Johnson <iris.gates(a)gmail.com> wrote:
> Umm. Non-happy camper. ISP things have changed here, without me being
> informed. Recently (2 days ago) my modem started rebooting every little
> while. Zillions of T3 & T4 timouts in the modem log, Signal lavels were
> perfect when it was online. I own this thing, a Motorola SB6120 purchased
> late June 2010. It has not been abused.
>
> I am in Woosta & we all know the ISP available here. 2 techs showed up
> mid-morning, to diagnose and fix this issue. One guy stood there watching;
> the other guy "did stuff." They checked the signal levels on incoming line
> from the box connected to the pole our back, and declared my moden Dying.
> They talked to each other (not me) & seemed to think I was Granny-in-a-Box,
> until they let me say more than one sentence.
>
> These guys also confessed that since July 202, Ch4rter does not "allow"
> customers to own/run their own modems. Their consolation prize is that they
> don't charge modem rental fees any more. (it's not on the bill, anyway,
> FWIW). They mumbled some other mumbo jumbo and fled 5 seconds after they
> learned I have my own router too, & didn't care if the modem and router
> were yet in communication. They just said "better reboot" and they "no
> longer" service "wireless" --which I am not running except when certain
> visitors appear. I think they meant they don't diagnose routers, which has
> always been the policy, and which is fine. Internal LAN issues aren't their
> problem.
>
> So now I have a modem which may or may not be sick, but no way to test it
> to make sure. Is there anyone here who can take a look at this thing & test
> to see if it's Really Dying, or if Ch4rter deaded it with their latest
> firmware revision of their firmware & policy change in July 2012?
>
> An interesting meeting theme sometime might be how to get the Verizon FIOS
> in Worcester. Several years ago I watched Verizon trucks & Verizon moles
> installing their fiber optics in manholes all over town. Ch4rter is running
> on Verizon's infrastructure. Ch4rter internet has been working better since
> then, but we're still locked out of the option to use verizon. Is this a
> topic of interest to anyone? If so, I'll lead the discussion and even buy
> the Pizz4. To me, this is a Large Pizza problem.
>
> Another interesting but probably futile discussion might center around why
> we have suddenly been deprived of the ability to watch the behavior and
> effectiveness of our modems, which serve internet coming from our ISP.. I
> was not informed of this -- was anyone who is just a 'regular' customer?
>
> Meanwhile, if anyone has a test lab or whatever, where they can test my
> declared-dead modem, please let me know. Otherwise it's probably a
> giveaway, or another piece of Landfill Fodder. I can bring to a meeting &
> can wait for results.
>
> Thanks & happy pizzaz,
> Liz J
>
>
>
>
>
>
>
13 years
Re: [EXT] The future of WLUG
by Tim Keller
I've gotten a couple of hits about people possibly showing up for the next
WLUG meeting from meetup. That's cool!
I went looking at the Boston Linux Users Group site and it's clear to me
that we're really missing the boat with putting our meetings on youtube,
well at least the ones with a definite presenter.
Would people be freaked out about being on youtube? Is this something that
people would be interested in? I've got a decent DSLR we could use to take
video, but I don't want people to be uncomfortable.
Tim.
On Sun, Jan 12, 2020 at 1:41 PM <joshua.gage.stone(a)gmail.com> wrote:
> Tim,
>
> Thank you very much for creating a meetup.com group for us! The UX for
> finding future meetups and adding meetup dates to a calender is quite good.
> Finding WLUG should also be fairly easy now when searching for "linux"
> within a 50 mile radius of Boston:
>
>
> https://www.meetup.com/find/?allMeetups=false&keywords=linux&radius=50&user…
>
> I've noticed that some search strings will show LUGs with overlapping
> interests but not WLUG. I think adding more words like "FOSS", "Android",
> "Libre", "Open Source", "Ubuntu", "Fedora", "OpenSUSE", "Arch Linux",
> "Unix", etc, to the related topics and/or What We're About section should
> improve this.
>
> I've tried setting up a community over Slack but I think the steps need to
> join was what made it too intrusive for new people -- take joining the Rust
> language Slack server for example:
>
> https://rust-slack.herokuapp.com/
>
> - Send an invite link to your email
> - Register with a name and password
> - Be greeted with prompts about whether to send notifications
> - Open the #general channel
>
> And this has to be repeated for joining every community that has their own
> Slack server, or at least this has been my experience so far. I think Slack
> has cemented itself as more of a means for teams to collaborate on a
> project, not so much for casual users who want to jump right into a new
> chat.
>
> Matrix only needs to register a username and password (email is optional)
> on the server you're on, and once that's done you can join any number of
> channels on that server. This is much closer to the UX of IRC, and it's
> still superior in some ways because there's no fiddling with choosing a
> specific authentication method like SASL and/or authenticating with nickserv
>
> I think in general Matrix has more mindshare amongst Linux users as a
> modern alternative to IRC, which I think is worth considering when
> comparing frequency of posts on Reddit:
>
>
> https://old.reddit.com/r/linux/search?q=matrix&restrict_sr=on&sort=relevanc…
>
> -Josh
>
> On Sat, 2020-01-11 at 22:59 -0500, Tim Keller via WLUG wrote:
>
> This morning I went out and created a meetup group for WLUG:
> https://www.meetup.com/Worcester-Linux-Users-Group and paid for six
> months. Feel free to go and join up if you'd like.
>
> The matrix stuff is cool, I cut my teeth on IRC so I'm always partial to
> the old school but I also understand that eventually we'll want a slack
> channel as well maybe.
>
> Tim.
>
>
>
> On Fri, Jan 10, 2020 at 4:07 PM Anderson, Charles R via WLUG <
> wlug(a)lists.wlug.org> wrote:
>
> We also have an IRC channel:
>
> http://www.wlug.org/participate.html
>
> Internet Relay Chat
>
> Join the realtime chat on our IRC channel.
>
> Connect your IRC client to irc.freenode.net
> Join the #wlug-ma channel or join directly from this link: irc://
> irc.freenode.net/#wlug-ma.
> See more information about Freenode and join the chat from your web
> browser
>
> but maybe IRC is too old school--no one chats on it anymore.
>
> On Fri, Jan 10, 2020 at 04:03:14PM -0500, Joshua Stone via WLUG wrote:
> > Hey all,
> >
> > Last night's meeting was excellent, and I'd like say thanks again to
> > Tim for giving me a ride home!
> >
> > Last night's discussion gave me ideas of ways we could improve general
> > activity, increase attendence, and improve outreach efforts. Hosting a
> > meetup.com group would be certainly improve discoverability, and
> > getting in touch with WPI's computer science group would be great too.
> >
> > I think what a lot communities are doing nowadays is having a text chat
> > format for users who want to communicate more easily over the internet,
> > especially with mobile devices. As an example, there are Discord
> > servers for Fedora, Ubuntu, OpenSUSE, etc, and they have room sizes
> > generally in the hundreds or even well over a thousand. Even before
> > Discord they'd use IRC for providing support, posting updates, etc.
> >
> > Having a text chat of our own would certainly help improve
> > participation -- I think Matrix would be a good option here because it
> > has many nice features and has a fairly polished user experience:
> >
> > - Numerous clients available on desktop, mobile, and web (
> > https://matrix.org/clients/
> > - Persistent chat history
> > - Link previews
> > - Various bots to choose from for adding functionality (
> > https://matrix.org/docs/projects/bots/
> > - User moderation
> > - Server federation
> > - Self-hosting available, both client and server are completely FOSS
> > - File sharing
> > - Voice/video calls
> >
> >
> > I have a screenshot if anyone wants to see what a Matrix chat room
> > would look like:
> >
> > https://i.imgur.com/aVILcWB.png
> >
> > Or you can join the room I made:
> >
> > https://matrix.to/#/!EiTljkvagZDFKfQfFu:matrix.org?via=matrix.org
> >
> > Alteratively, if you have a Matrix client already:
> >
> > #wlug:matrix.org
> >
> >
> >
> > Any thoughts?
> >
> >
> > -Josh
> _______________________________________________
> WLUG mailing list -- wlug(a)lists.wlug.org
> To unsubscribe send an email to wlug-leave(a)lists.wlug.org
>
>
>
> _______________________________________________
>
> WLUG mailing list --
>
> wlug(a)lists.wlug.org
>
>
> To unsubscribe send an email to
>
> wlug-leave(a)lists.wlug.org
>
>
>
--
I am leery of the allegiances of any politician who refers to their
constituents as "consumers".
5 years, 9 months
Re: Stuck in traffic
by John Stoffel
>>>>> "Althea" == Althea Shaheen <lists(a)altheashaheen.com> writes:
> I would love to hear more from you John about what your experience
> is with TrueNAS Enterprise versus NetApp, as I am looking at the
> same options myself. We have used NetApp for longer than I have been
> around but the cost of it is a whole different level than what I
> imagine TrueNAS would be. I've used Scale personally and Core for
> backup systems at work, but the HA/failover is what I am most
> curious about if we went the route of Enterprise.
With Netapp... it's solid. Rock solid. It just works. Failover
works, no interrupptions with clients. It's really really really
solid. I love them. And you can split things up and add tons of
VLANs, volumes, etc. Snapshots, ESX integration if you want to go
that route, etc. But it's not cheap. You pay for what you get. It's
annoying that they now do capacity based licensing.
TrueNAS. It's easy enough to use (though the CLI sucks, I've got a
bunch of scripts to pull data out using the API with python). I'm
using the legacy 13.0 Enterprise BSD based stuff. TrueNAS recently
moved to the linux based SCALE edition, but I have no experience with
it.
So far performance is good, it's ZFS, and it just runs. But we're not
putting it under huge performance stress, so I can't talk to how well
it scales or performs.
I've used Netapps for 26+) years now. Super solid systems. I love
how you can grow/shrink volumes (NFS/CIFS) on the fly. No hassles.
TrueNAS is fixed volumes you can expand only.
So you need to look at Scale Enterprise and see what they will quote
you for support, and maybe you can get in a test system to see how
failover works. In my case, since TrueNAS Enterprise is
Active/Passive, failover takes too long in my book.
Sorry, this reply is all over the place as I free associate my reply.
> On Fri, Oct 11, 2024, at 09:36, John Stoffel via WLUG wrote:
>>>>>>> "Tim" == Tim Keller via WLUG <wlug(a)lists.wlug.org> writes:
>>
>>> I'm currently stuck in traffic I should be there for about 7:10
>>
>> So how did the meeting go? Any comments or thoughts on ZFS and how
>> it's useful and how it can be abused?
>>
>> I'm using ZFS on a TrueNAS Enterprise cluster, which works, but has
>> it's issues, mostly around failover speed. Been spoiled by Netapps
>> for too many years.
>>
>> I've also managed to make Oracle branded ZFS appliances fall over due
>> to load, so I have reservations about ZFS to this day.
>>
>> I do like the *ideas* behind it, and some of the powerful features it
>> has. But the layering violations make me worry.
>>
>> Just go look at the problems btrfs has had trying to do it's own RAID5
>> instead of just layering on top of MD RAID5 (which I also admit has had
>> problems too! Nothing is perfect...).
>>
>> The goals of ZFS in terms of file content checksums are awesome, I
>> really like that. I just wish there was a better way to actually
>> shrink ZFS filesystems (even if done as any offline process) without
>> jumping through all kinds of hoops.
>>
>> Anyway, I hope to see you all at the next meeting!
>> John
>> _______________________________________________
>> 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/SQAQ6…
1 year
Reminder: BBQ this Thursday August 12 6pm, Boylston, MA
by Chuck Anderson
Consider this your reminder for the BBQ this Thursday! Rain or shine,
we're on. I'm told that the mosquitos are non-existant this year!
On Sun, Jul 25, 2010 at 11:08:30AM -0400, Chuck Anderson wrote:
> Hi WLUG members,
>
> It's that time a year again for the WLUG BBQ! Thanks to Doug Mildram
> for hosting again this year. We will be holding the BBQ on the
> scheduled date of our next meeting, but starting at 6pm:
>
> Thursday, August 12 at 6:00 PM
>
> Doug has provided these directions and contact information:
>
> For Worcester area:
>
> http://webpages.charter.net/mquinty/directions/boylston_from_auburn_worc_29…
>
> From the Northwest such as Leominster:
>
> http://webpages.charter.net/mquinty/directions/boylston_from_rte2_lancaster…
>
> From anywhere via 495:
>
> http://webpages.charter.net/mquinty/directions/boylston_from_495+62.txt
>
> WLUG will supply burgers, hot dogs, rolls/buns, condiments, paper
> products, soda, etc. BYOB, dessert, and other food/snack items as you
> like.
>
> Please email Doug (dmildram(a)gmail.com) with any questions.
>
> I look forward to seeing everyone there!
> Chuck
15 years, 2 months
Re: [Wlug] ZFS on Linux vs. BTRFS or stick with EXT4?
by Jeff Moyer
Chuck Anderson <cra(a)WPI.EDU> writes:
> I'm migrating to new large drives and would lke to take advantage of a
> filesystem that has integrated data and metadata checksums. How well
> does ZFS on Linux really work? What is the current status of BTRFS?
> Which one would you trust your precious data to? I've been out of the
> loop lately... This would be a great meeting topic! "How to set up
> ZFS on Linux and/or BTRFS". Any takers?
I wouldn't trust my data to btrfs, especially if you're using anything
other than the default mkfs and mount options. But don't take my word
for it, have a look through the btrfs mailing list archives[1].
I have no experience with zfs on linux, but I've heard that data
checksums have a signficant performance impact. I don't have any data
on that, so you should probably do your own benchmarking to verify
things perform well enough for your workload.
If I were you, I'd use xfs.
Cheers,
Jeff
[1] http://marc.info/?l=linux-btrfs
10 years, 5 months
Re: [Wlug] ZFS on Linux vs. BTRFS or stick with EXT4?
by Chuck Anderson
Hi Jeff, its nice to provoke a response out of you...when are you
coming to a meeting? :-)
On Wed, Apr 29, 2015 at 09:40:09AM -0400, Jeff Moyer wrote:
> I wouldn't trust my data to btrfs, especially if you're using anything
> other than the default mkfs and mount options. But don't take my word
> for it, have a look through the btrfs mailing list archives[1].
I see what you mean. People are still asking questions "how do I fix
this broken fs?" and being told to upgrade to linux kernel 4.0.
> I have no experience with zfs on linux, but I've heard that data
> checksums have a signficant performance impact. I don't have any data
> on that, so you should probably do your own benchmarking to verify
> things perform well enough for your workload.
>
> If I were you, I'd use xfs.
I don't like XFS because it can't be shrunk in place. Too many times
I've needed to shrink one LV to make space for another LV.
10 years, 5 months
Re: [Wlug] Book list with names.
by Randall Mason
I would like the hacking books.
Randall Mason
randall(a)mason.ch
On Thu, Aug 20, 2009 at 1:41 PM, Sebastian Courtney <
sebastian.courtney(a)gmail.com> wrote:
> Unfortunately I must a tend a wake tonight so I will not make the meeting.
> Feel free to disperse the books I wanted to others.
> See you all at the next meeting,
> Sebastian
>
>
> On Sat, Aug 15, 2009 at 3:17 PM, Tim Keller <turbofx(a)gmail.com> wrote:
>
>> It's yours!
>>
>>
>>
>> On 8/15/09, Eric Martin <freak4uxxx(a)gmail.com> wrote:
>> > I would like to claim "Web Hacking: Attacks and Defense" as it looks
>> > like nobody else has yet.
>> >
>> >
>> >> Hacking / Security Books:
>> >> "Secrets of a super hacker" by The Knightmare.
>> >> [S. Courtney] "Hackers Challenge: Test Your Incident Response Skills
>> >> Using 20 Scenarios" (3rd Edition)
>> >> [S. Courtney] "Hacking Exposed: Network Security Secrets & Solutions"
>> > "Web Hacking: Attacks and Defense"
>> >>
>> >> Math Books:
>> >> [Frank Moody] "Discrete Mathematics and Its Applications" by Kenneth H.
>> >> Rosen
>> >> [Frank Moody] "Languages and Machines" Thomas A Sudkamp
>> >> [Alex Haley] "A Primer for Calculus"
>> >>
>> >> Misc:
>> >> [Alex Haley] "Latex" Second edition
>> >> [Frank Moody] "The Latex Companion"
>> >> [Frank Moody] "Mips RISC Architecture"
>> >> "Database Systems"
>> >> "Creating Web Pages with HTML" (3rd edition)
>> >> [Frank Moody] "Operating Systems: Design and Implementation": Tanenbaum
>> >> (includes Minux 2.0 disk!!)
>> >> [Frank Moody] "PCI System Architecture" (Third Edition)
>> >>
>> >> Programming Books:
>> >> [Alex Haley] "The C Primer" Third edition (this book is a bit dog
>> eared)
>> >> [Alex Haley] "A First Book of Ansi C" (a bit dog eared but excellent)
>> >> "Tricks of the Game Programming Gurus"
>> >> "Practical Programming in Tcl and Tk"
>> >> "Virtual Reality Playhouse"
>> >> "Creating Turbo C++ Games" (The disk for this book is long lost)
>> >> [Keith Wright] "Linux Kernel Programming" (Third Edition)
>> >> "Using Java 1.1" (Third Edition)
>> >> "Using JavaBeans" (CD Long gone)
>> >> [S. Courtney] "Sams' Teach Yourself C++ in 21 Days" (Second Edition)
>> >> "Beginning Fedora 2" (Yeah it's 8 versions behind, but as a beginners
>> >> guide to red hat linux systems, it's great)
>> >> "User Interfaces In C++ And Object-Oriented Programming" by Mark
>> Goodwin
>> >> "Gardens of Imagination: Programming 3d Maze Games in C/C++" (Disk long
>> >> gone)
>> >> "NetWarriors In C Programming 3d Multiplaery games" (CD Long gone)
>> >> [Ryan Pugatch] "Programming perl" (O'Reilly)
>> >> [Ryan Pugatch] "Learning Perl" (O'Reilly)
>> >> [Ryan Pugatch] "Perl by Example" (Ellie Quigley)
>> >>
>> >> Thanks,
>> >> Tim.
>> > --
>> > Eric Martin
>> > Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
>> >
>> >
>>
>> --
>> Sent from Gmail for mobile | mobile.google.com
>>
>> I am leery of the allegiances of any politician who refers to their
>> constituents as "consumers".
>> _______________________________________________
>> Wlug mailing list
>> Wlug(a)mail.wlug.org
>> http://mail.wlug.org/mailman/listinfo/wlug
>>
>
>
>
> --
> Sebastian Courtney
> WPI 2012
> ECE+RBE
> 617-894-2460
>
> _______________________________________________
> Wlug mailing list
> Wlug(a)mail.wlug.org
> http://mail.wlug.org/mailman/listinfo/wlug
>
>
16 years, 1 month
Re: Wlug meeting on Thurs. Dec 10th 2020 @7pm.
by Chuck Anderson
This might not be as bad as it initially sounds. Centos Stream will
consist of rolling updates that start from what will become each RHEL
point release to what will become the the next RHEL point release, so
for example from RHEL 8.1 to 8.2 to 8.3 etc. In fact, Centos 6, 7,
and 8 already is a "forced" minor upgrade every quarter or so since
they stop supporting x.y after RHEL x.y+1 comes out and your normal
system yum updates just migrate you to the newer x.y+1 anyway. This
is in contrast to how RHEL itself works, or how Scientific Linux used
to work, where you actually have to take explicit action to upgrade to
a new point release either using new install media or manual "yum"
commands. See for example:
https://scientificlinux.org/documentation/faq/faq-releases/
And here is what one of my Centos 7 systems looks like:
>cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)
>rpm -qf /etc/centos-release
centos-release-7-9.2009.1.el7.centos.x86_64
>rpm -qi centos-release
Name : centos-release
Version : 7
Release : 9.2009.1.el7.centos
Architecture: x86_64
Install Date: Thu 03 Dec 2020 07:27:24 AM EST
..
See how the Centos 7.9.2009 release package was installed this month?
Previously, I had older versions of that package:
>sudo grep centos-release /var/log/yum.log*
/var/log/yum.log:Nov 13 08:46:49 Updated: centos-release.x86_64 7-9.2009.0.el7.centos
/var/log/yum.log:Dec 03 07:27:24 Updated: centos-release.x86_64 7-9.2009.1.el7.centos
/var/log/yum.log-20181204:Jul 30 14:47:20 Updated: centos-release-7-5.1804.el7.centos.2.x86_64
/var/log/yum.log-20181204:Aug 14 12:15:35 Updated: centos-release-7-5.1804.4.el7.centos.x86_64
/var/log/yum.log-20181204:Oct 10 05:45:04 Updated: centos-release.x86_64 7-5.1804.5.el7.centos
/var/log/yum.log-20181204:Dec 04 07:19:18 Updated: centos-release.x86_64 7-6.1810.2.el7.centos
/var/log/yum.log-20200428:Jan 08 09:08:24 Updated: centos-release-7-7.1908.0.el7.centos.x86_64
/var/log/yum.log-20200428:Apr 28 07:47:22 Updated: centos-release.x86_64 7-8.2003.0.el7.centos
So over the years, this server got upgraded automatically from Centos
7.5 to 7.6 to 7.7 to 7.9. I have nightly automatic "yum updates"
turned on, so it just gets updates as they come out and I reboot the
server once every so often so the updates get fully applied (new
kernels, new shared libraries).
The difference with Centos Stream is you'll get updates continually
/before/ RHEL releases it eventually as a "snapshot in time" called
RHEL x.y+1. Sure, they won't be as heavily tested as RHEL point
releases, but if you really need/want that, then you can either buy
RHEL or stage your Centos Stream updates from TEST-->STAGE-->PROD,
and/or stagger them across your PROD systems to minimize impact.
On Wed, Dec 09, 2020 at 02:59:30PM -0500, Tim Keller wrote:
> I've got a fair amount of centos in production... this sucks... guess I'm
> going to Debian now...
>
> On Wed, Dec 9, 2020 at 9:10 AM Frank Sweetser via WLUG <wlug(a)lists.wlug.org>
> wrote:
>
> > And for anyone looking to contribute to Greg's efforts:
> >
> > https://github.com/hpcng/rocky
> >
> > On Tue, Dec 8, 2020 at 11:23 PM Chuck Anderson via WLUG <
> > wlug(a)lists.wlug.org> wrote:
> >
> >> My favorite comment on that post:
> >>
> >> "Gregory Kurtzer says:
> >> December 8, 2020 at 4:27 pm
> >>
> >> I am considering creating another rebuild of RHEL and may even be able
> >> to hire some people for this effort. If you are interested in helping,
> >> please join the HPCng slack (link on the website hpcng.org)
> >>
> >> Greg
> >> (original founder of CentOS)"
> >>
> >> On Tue, Dec 08, 2020 at 10:35:24PM -0500, Frank Sweetser via WLUG wrote:
> >> > Well, there's plenty talk about for CentOS users, like what you're
> >> going to
> >> > switch to now that CentOS is becoming something completely different:
> >> >
> >> > https://blog.centos.org/2020/12/future-is-centos-stream/
4 years, 10 months