Thursday, November 6, 2014
FuzixOS: Because Small Is Beautiful
FuzixOS: Because Small Is Beautiful
Linux kernel developer Alan Cox has come up with an excellent new toy. In recent months, he has reported working with several older hardware platforms ... just for fun. And now, he has published FuzixOS on Github.
In the open source world, I've been noticing a loss of simplicity lately. Fuzix is one alternative to the bloat. It's a collection of features from UZI and various Unix for 8-bit systems. Yes, in terms of anti-bloat, this is extreme. But it's cool!
Can't help but think about NORD in this context. The prime motivator for NORD is the need for simplicity. If Fuzix gets a little more robust, maybe some of the FOSS packages in NORD can be tried on Fuzix. ("Portable Apps" will require sym-links, but the CSCRATCH parts will likely work straight away.) It might even be possible to use the Fuzix kernel for a "real" NORD build.
-- R; <><
Monday, September 22, 2014
Impending Internet
Impending Internet
I heard a respected software engineer say something like, "I saw the advent of the web, and that turned out to be right. I saw Linux on virtualization, and that turned out to be right.". Personally I felt a little vindicated because I had seen the same things. But I was frustrated by his comment because this guy also does not see some impending changes of our landscape.
Impending ... as if something is yet to be.
Case in point, IPv6. I've been pitching IPv6 for the platforms I support for several years. But a number of my peers just don't like it. They don't want to "do" IPv6 until they have to. I gotta think that the procrastination is from ignorance: I suspect that they think IPv6 is difficult. It's not.
IPv6 is not impending. It's now. "It's soooo yesterday!"
As for me, I hate being forced into something, even if it's something that I like, something cool or fun. I got into IPv6 with help from the Orc almost four years ago. Had been trying on my own to crack into IPv6 for the better part of a decade. In the end, I got by with a little help from my friend.
Then today's news, not specifically about IPv6, but tangentially related. I heard about a Chinese government hack against SSL. The targeted network is their CERNET education and research network, which it turns out is entirely IPv6 (CERNET2, at least). Here's my chance to say it: told ya. The Asian tech sector is way ahead of Europe and the Americas on this front.
Most of the major shops have a complete IPv6 rollout underway, many nearly complete. So ... there's plenty of examples of getting this done. C'mon, try with a little help from your friends.
-- R; <><
I heard a respected software engineer say something like, "I saw the advent of the web, and that turned out to be right. I saw Linux on virtualization, and that turned out to be right.". Personally I felt a little vindicated because I had seen the same things. But I was frustrated by his comment because this guy also does not see some impending changes of our landscape.
Impending ... as if something is yet to be.
Case in point, IPv6. I've been pitching IPv6 for the platforms I support for several years. But a number of my peers just don't like it. They don't want to "do" IPv6 until they have to. I gotta think that the procrastination is from ignorance: I suspect that they think IPv6 is difficult. It's not.
IPv6 is not impending. It's now. "It's soooo yesterday!"
As for me, I hate being forced into something, even if it's something that I like, something cool or fun. I got into IPv6 with help from the Orc almost four years ago. Had been trying on my own to crack into IPv6 for the better part of a decade. In the end, I got by with a little help from my friend.
Then today's news, not specifically about IPv6, but tangentially related. I heard about a Chinese government hack against SSL. The targeted network is their CERNET education and research network, which it turns out is entirely IPv6 (CERNET2, at least). Here's my chance to say it: told ya. The Asian tech sector is way ahead of Europe and the Americas on this front.
Most of the major shops have a complete IPv6 rollout underway, many nearly complete. So ... there's plenty of examples of getting this done. C'mon, try with a little help from your friends.
-- R; <><
Sunday, July 13, 2014
Proposing Powerful Portable Pipelines
Proposing Powerful Portable Pipelines
IBM calls the package CMS/TSO Pipelines. A certain group of us affectionately call it "Hartmann Pipes". It's standard equipment on VM/CMS, but a lot of people upgrade to the author's version. On TSO (part of z/OS), it's optional. Those who learn even the simplest of its capabilities tend to get really hooked on it.
When you're excited about something, you talk about it. But discussing Hartmann Pipelines with the uninitiated is difficult. Most people have seen command line pipes (Unix, Linux, even Windows) so they wonder "what's the big deal?". How is this implementation different from other pipelining schemes? Aye, there's the rub. I'll get into that detail later. And some readers will need that rationale before any of this makes sense. First ... the proposal.
There are two audiences. There are those who don't know CMS Pipelines. I gotta sell you on this wonderful thing. There are those who do know CMS Pipelines. I gotta sell you on this particular implementation. It includes a compromise; I gotta sell you on the compromise. Maybe from the two groups there will be enough volunteers to achieve critical mass.
The Proposal
There have been several ports of pipelines. Prior efforts require one or more substantial support environments. The idea here is to use pure C. Interaction between the stages is summarily handled by these functions ...
output() is used by a producer stage. The producer is blocked until the record is consumed. p is a pipe struct pointer, referencing a connection, in this case an output connector. d points to the data, but it's not necessarily a NULL terminated character string. There are no sacred characters. l says how long the record is.
peekto() and readto() are used by a consumer stage. They're identical except that peekto() leaves the record pending, and leaves the producer stage blocked. p is a similar pipe struct pointer to that used for output(), except that it references an input connector. b points to a buffer and l indicates its size.
These are easily implemented on any POSIX system using a pair of traditional pipes. We'll have one Unix style pipe pointed "downstream" sending data and stats, and another pointed "upstream" sending control signals. Some of the control signals are ...
The producer accepts these controls via the upstream pipe and sends meta data or data on via downstream pipe. The producer blocks until it gets a "got it" signal from the consumer. The consumer blocks until the producer has a record to send.
The "connector" struct starts with two file descriptors ...
struct PIPECONN {
int ctrl; /* control from consumer to producer */
int data; /* data from producer to consumer */
... other elements ...
}
The data pipe alternately carries metadata based on signals on the ctrl pipe.
The Compromise
The above operations are under control of the host operating system. Some time back, I mentioned this idea to the Piper (Hartmann himself). His take on it was not clear. CMS Pipelines has its own dispatcher. (CMS originally did not have built-in multi-tasking.) I've mentioned the idea to several serious plumbers. They unanimously reject it, citing Hartmann's dispatcher as an essential requirement. But is it?
About the time I first published this article, David Craig shared his excursion into Plan 9 (that's a whole nutha journal entry) including discussion about Plan 9 security. I found this ...
The point goes for more than just security. A weak (or not well tuned) but easy-to-use dispatcher can be more effective if it leads to a simpler implementation. So that's to the Pipes knowing audience. Let each stage be a unique process.
Now a word to the uninitiated.
A Record by Any Other Name
Hartmann Pipes convey records. "Eww ... such a mainframe concept." Well, yes, in fact. John Hartmann invented Pipelines on a mainframe and CMS/TSO Pipes runs on two mainframe operating systems.
Why do we fight over these things? If it were called a packet or a message or perhaps a block then you wouldn't have a problem with it. I won't enumerate the reasons for using quantized data (records) leaving examples such as MQ and TCP as ample justification.
The value of the Hartmann implementation includes ...
We could really use this on systems other than only CMS and TSO.
-- R: <><
Originally published 2014-July-13.
IBM calls the package CMS/TSO Pipelines. A certain group of us affectionately call it "Hartmann Pipes". It's standard equipment on VM/CMS, but a lot of people upgrade to the author's version. On TSO (part of z/OS), it's optional. Those who learn even the simplest of its capabilities tend to get really hooked on it.
When you're excited about something, you talk about it. But discussing Hartmann Pipelines with the uninitiated is difficult. Most people have seen command line pipes (Unix, Linux, even Windows) so they wonder "what's the big deal?". How is this implementation different from other pipelining schemes? Aye, there's the rub. I'll get into that detail later. And some readers will need that rationale before any of this makes sense. First ... the proposal.
There are two audiences. There are those who don't know CMS Pipelines. I gotta sell you on this wonderful thing. There are those who do know CMS Pipelines. I gotta sell you on this particular implementation. It includes a compromise; I gotta sell you on the compromise. Maybe from the two groups there will be enough volunteers to achieve critical mass.
The Proposal
There have been several ports of pipelines. Prior efforts require one or more substantial support environments. The idea here is to use pure C. Interaction between the stages is summarily handled by these functions ...
- output(p,d,l) /* blocks until record is consumed */
- peekto(p,b,l) /* examines a record without consuming */
- readto(p,b,l) /* consumes a record (and gets contents) */
output() is used by a producer stage. The producer is blocked until the record is consumed. p is a pipe struct pointer, referencing a connection, in this case an output connector. d points to the data, but it's not necessarily a NULL terminated character string. There are no sacred characters. l says how long the record is.
peekto() and readto() are used by a consumer stage. They're identical except that peekto() leaves the record pending, and leaves the producer stage blocked. p is a similar pipe struct pointer to that used for output(), except that it references an input connector. b points to a buffer and l indicates its size.
These are easily implemented on any POSIX system using a pair of traditional pipes. We'll have one Unix style pipe pointed "downstream" sending data and stats, and another pointed "upstream" sending control signals. Some of the control signals are ...
- tell me about the record
- give me the data, used by both peekto() and readto()
- unblock, "got it", producer can move along, used by readto()
The producer accepts these controls via the upstream pipe and sends meta data or data on via downstream pipe. The producer blocks until it gets a "got it" signal from the consumer. The consumer blocks until the producer has a record to send.
The "connector" struct starts with two file descriptors ...
struct PIPECONN {
int ctrl; /* control from consumer to producer */
int data; /* data from producer to consumer */
... other elements ...
}
The data pipe alternately carries metadata based on signals on the ctrl pipe.
The Compromise
The above operations are under control of the host operating system. Some time back, I mentioned this idea to the Piper (Hartmann himself). His take on it was not clear. CMS Pipelines has its own dispatcher. (CMS originally did not have built-in multi-tasking.) I've mentioned the idea to several serious plumbers. They unanimously reject it, citing Hartmann's dispatcher as an essential requirement. But is it?
About the time I first published this article, David Craig shared his excursion into Plan 9 (that's a whole nutha journal entry) including discussion about Plan 9 security. I found this ...
"... weak but easy-to-use security can be more effective
than strong but difficult-to-use security if it is more likely to be used."
than strong but difficult-to-use security if it is more likely to be used."
The point goes for more than just security. A weak (or not well tuned) but easy-to-use dispatcher can be more effective if it leads to a simpler implementation. So that's to the Pipes knowing audience. Let each stage be a unique process.
Now a word to the uninitiated.
A Record by Any Other Name
Hartmann Pipes convey records. "Eww ... such a mainframe concept." Well, yes, in fact. John Hartmann invented Pipelines on a mainframe and CMS/TSO Pipes runs on two mainframe operating systems.
Why do we fight over these things? If it were called a packet or a message or perhaps a block then you wouldn't have a problem with it. I won't enumerate the reasons for using quantized data (records) leaving examples such as MQ and TCP as ample justification.
The value of the Hartmann implementation includes ...
- record structure (if any) is retained
- "delaying the record" can be tolerated or avoided, as needed
- an entire record can be examined before it is consumed, which allows for in-flight changes to the pipeline based on content
- a stage can be added, to input or output, between two connected stages
- multiple streams can run concurrently, and fan-in or fan-out
- output can be looped back to input
We could really use this on systems other than only CMS and TSO.
-- R: <><
Originally published 2014-July-13.
Tuesday, May 27, 2014
Data Sharing versus Data Security
Data Sharing versus Data Security
Two of my favorite topics that seem to contradict each other are the sharing of data and the securing of it (especially crypto). I'll be pitching both at the upcoming VM and Linux Workshop next month at NC A&T in Greensboro. What's really amazing at this time is how hot both topics are and yet how poorly understood they are.
The VM and Linux Workshop is an highly technical and surprisingly inexpensive conference. This year there will be the added value of Velocity Software's performance seminar two days prior to the workshop (at the same location).
Data Sharing
The glut of mobile computing and popularity "cloud computing" illuminates the need for data sharing ... even amplifies it. For just one example, think about your list-o-contacts on your smart phone. Handy, eh? But not so handy if you have to go into contortions to synchronize the info with other parts of your digital life. Gotta have data synch, and that's data sharing.
Full disclosure: the presentation will specifically cover filesystem sharing, though we'll touch on data synch and other such content manglement. Networked filesystems were more common until recently. In a context where applications use files, network sharing of filesystems makes a lot of sense. But even where apps use methods other than files for their working data, they need files for basic operation. And here's the kicker: most of the operating system needs files. So ... sharing of filesystems makes a lot of sense in more contexts than you might think.
Sharing filesystems as block devices or memory is cooler: It is efficient, effective, even elegant. Sharing virtual disk or virtual ROM is obvious to some but still not practiced as widely as it should be. And sharing disk images works in SAN land as well as in the virtual world. "It's everywhere you want to be."
Data Security
We're talking crypto, but not just crypto. (Controlling access is crucial.)
I mentioned smart phone and contacts. Data sec balances data sharing so that your contacts remain yours.
The presentation will cover a mere handful of the data access issues. (You could have a week long seminar discussing all related topics!) For the focus topic of SSL, it's vital to protect the server's secret key.I'll get into how that works, why its important, and related tools (PGP/GPG and SSH and others). Ciphers and hashes and keys ... oh my!
Truth be told, PKI is a mess, but it gives us a framework, a reference. The heavy lifting is done by SSL (and TLS) which is really slick, well defined, and robust. But the underlying cryptography is a moving target. As soon as you learn one cipher or hash, you find it has been defeated. So keeping things plug-compatible is essential.
Both of these topics border on obsession for me. They're so geeky cool. More people should use them. Even where they're not applicable, they should be considered ... part of your "doctor's bag" of remedies and treatments. I'm excited to be talking at the Workshop again.
-- R; <><
Two of my favorite topics that seem to contradict each other are the sharing of data and the securing of it (especially crypto). I'll be pitching both at the upcoming VM and Linux Workshop next month at NC A&T in Greensboro. What's really amazing at this time is how hot both topics are and yet how poorly understood they are.
The VM and Linux Workshop is an highly technical and surprisingly inexpensive conference. This year there will be the added value of Velocity Software's performance seminar two days prior to the workshop (at the same location).
Data Sharing
The glut of mobile computing and popularity "cloud computing" illuminates the need for data sharing ... even amplifies it. For just one example, think about your list-o-contacts on your smart phone. Handy, eh? But not so handy if you have to go into contortions to synchronize the info with other parts of your digital life. Gotta have data synch, and that's data sharing.
Full disclosure: the presentation will specifically cover filesystem sharing, though we'll touch on data synch and other such content manglement. Networked filesystems were more common until recently. In a context where applications use files, network sharing of filesystems makes a lot of sense. But even where apps use methods other than files for their working data, they need files for basic operation. And here's the kicker: most of the operating system needs files. So ... sharing of filesystems makes a lot of sense in more contexts than you might think.
Sharing filesystems as block devices or memory is cooler: It is efficient, effective, even elegant. Sharing virtual disk or virtual ROM is obvious to some but still not practiced as widely as it should be. And sharing disk images works in SAN land as well as in the virtual world. "It's everywhere you want to be."
Data Security
We're talking crypto, but not just crypto. (Controlling access is crucial.)
I mentioned smart phone and contacts. Data sec balances data sharing so that your contacts remain yours.
The presentation will cover a mere handful of the data access issues. (You could have a week long seminar discussing all related topics!) For the focus topic of SSL, it's vital to protect the server's secret key.I'll get into how that works, why its important, and related tools (PGP/GPG and SSH and others). Ciphers and hashes and keys ... oh my!
Truth be told, PKI is a mess, but it gives us a framework, a reference. The heavy lifting is done by SSL (and TLS) which is really slick, well defined, and robust. But the underlying cryptography is a moving target. As soon as you learn one cipher or hash, you find it has been defeated. So keeping things plug-compatible is essential.
Both of these topics border on obsession for me. They're so geeky cool. More people should use them. Even where they're not applicable, they should be considered ... part of your "doctor's bag" of remedies and treatments. I'm excited to be talking at the Workshop again.
-- R; <><
Wednesday, May 7, 2014
Sir Santa Seen in Super Set Script
Wednesday, March 5, 2014
Dave Tuttle's Memoirs
Dave Tuttle's Memoirs
I suppose some people think they're in it just for the money or just for the tech or just for the business. Maybe. But human nature consistently shows us that we need something more. Ultimately, it's that "image of God" creativity, even for those who think we're not terribly creative (and those who know we're not terribly god-like or even godly).
Why do you do what you do?
In software, especially in FOSS, why do you code the code you code?
Intrigue
I attended a Git workshop this past Monday evening. (Yeah, yeah ... it's about time. Hey! It's not like I don't use code manglement, CVS, SVN, etc.) The class was taught by Aidan Feldman of github. Great stuff! Excellent quick workshop; got us all actually using Git on github. Anyway, he mentioned that Linus created Git. I asked if the legend was true ... that Linus did it over a weekend. The bastion of all human knowledge says Git was done in four days and fully operational in a matter of weeks. Ahhh... that's the good stuff.
Before Linus, there were other heroes: Vint and Vixie, Gettys and Garbee and Grace, Barber and Farber, John and John and Jonn (Eckert and Mauchly -vs- von Neumann, rivals), Brooks and Bartik, Kay and Cray, Englebart. I'm grasping at straws and leaving out dozens ... hundreds. But you get the idea.
Intrigue inspires and FOSS fosters freedom.
VM/CMS
In my day job, I work with CMS. No, not that CMS, this CMS. It's IBM's "Conversational Monitor System" (fka "Cambridge Monitor System" to show some history). CMS is a single user, single-tasking operating system hosted by the oldest viable hypervisor: VM/CP the "Control Program".
Hey ... hypervisor ... you know what that is! It's that thing Rosenblum created. Yeah.
Not exactly. Didn't mean to drip into sarcasm. If I haven't lost the audience, then what follows may be more inspiration than irritation.
VM/CP is arguably the best hypervisor, and CMS (in spite of its warts) has been able to focus on a handful of incredible things, including CMS UPDATE. (We did mention code management, you recall.) I love this stuff!
Virtualization rocks! With CP under it, CMS is truly useful. XEDIT, REXX, Pipelines, a CISC processor and a full-featured assembler (plus C and other languages), that multi-level source code update tool, even OpenVM (yes, there's a shell, and yes, that part is multi-tasking).
History of VM
In the glory days of VM, Melinda Varian put together the often cited and repeatedly praised "VM and the VM Community: Past, Present, and Future". Her work ranks up there with Tracy Kidder's "The Soul of a New Machine", though less well known (and without the assist of a publisher).
I was already a fan of VM when I saw Melinda present at a SHARE conference. Hearing the history, the stories of how the system came to be, it all gave me chills. This is the system IBM tried to kill. Over and over.
The ultimate insult (to IBM) happened when Linux was ported to the mainframe. Linux works great on any platform, but is a teriffic candidate for virtualization, especially on high-redundancy hardware (like mainframes). There were two ports, by the way, one by IBM and another by Linas. No, not that Linus, and not that one either, this Linas. But that's a whole nutha story. (more intrigue!)
IBM sales guy: "Remember that system we told you to get rid of?"
IBM customer: "You mean VM? Sure. We got rid of it, like you told us."
IBM sales guy: "Well, you're gonna want it back."
IBM customer: [facepalm]
Addendum
The 1991 revision of Melinda's paper had a couple of addendums. I picked up printed copies. [remember paper?] One addendum was "Dave Tuttle's Memoirs". This is not usually seen alongside the newer revisions (of Melinda's work).
At one job, we were hosting lotso Linux on top of z/VM. (That company had never gotten rid of VM anyway.) Trying to inspire my teammates, I made copies of Tuttle's Memoirs and passed them around. [remember printed copies?] Some of the guys actually read it. These were good guys. I don't think they were in it for the money, maybe for the tech. We weren't coding, but I hope they were intrigued.
Given the myriad search engines available, you can probably find Mr. Tuttle's work for yourself. Here's one I found (other than my paper copy), starting about page 135:
http://www.cs.tufts.edu/~nr/cs257/archive/melinda-varian/neuvm.pdf
Enjoy! Be intrigued. Be inspired.
Someday I'd like to meet Dave Tuttle in person.
-- R; <><
I suppose some people think they're in it just for the money or just for the tech or just for the business. Maybe. But human nature consistently shows us that we need something more. Ultimately, it's that "image of God" creativity, even for those who think we're not terribly creative (and those who know we're not terribly god-like or even godly).
Why do you do what you do?
In software, especially in FOSS, why do you code the code you code?
Intrigue
I attended a Git workshop this past Monday evening. (Yeah, yeah ... it's about time. Hey! It's not like I don't use code manglement, CVS, SVN, etc.) The class was taught by Aidan Feldman of github. Great stuff! Excellent quick workshop; got us all actually using Git on github. Anyway, he mentioned that Linus created Git. I asked if the legend was true ... that Linus did it over a weekend. The bastion of all human knowledge says Git was done in four days and fully operational in a matter of weeks. Ahhh... that's the good stuff.
Before Linus, there were other heroes: Vint and Vixie, Gettys and Garbee and Grace, Barber and Farber, John and John and Jonn (Eckert and Mauchly -vs- von Neumann, rivals), Brooks and Bartik, Kay and Cray, Englebart. I'm grasping at straws and leaving out dozens ... hundreds. But you get the idea.
Intrigue inspires and FOSS fosters freedom.
VM/CMS
In my day job, I work with CMS. No, not that CMS, this CMS. It's IBM's "Conversational Monitor System" (fka "Cambridge Monitor System" to show some history). CMS is a single user, single-tasking operating system hosted by the oldest viable hypervisor: VM/CP the "Control Program".
Hey ... hypervisor ... you know what that is! It's that thing Rosenblum created. Yeah.
Not exactly. Didn't mean to drip into sarcasm. If I haven't lost the audience, then what follows may be more inspiration than irritation.
VM/CP is arguably the best hypervisor, and CMS (in spite of its warts) has been able to focus on a handful of incredible things, including CMS UPDATE. (We did mention code management, you recall.) I love this stuff!
Virtualization rocks! With CP under it, CMS is truly useful. XEDIT, REXX, Pipelines, a CISC processor and a full-featured assembler (plus C and other languages), that multi-level source code update tool, even OpenVM (yes, there's a shell, and yes, that part is multi-tasking).
History of VM
In the glory days of VM, Melinda Varian put together the often cited and repeatedly praised "VM and the VM Community: Past, Present, and Future". Her work ranks up there with Tracy Kidder's "The Soul of a New Machine", though less well known (and without the assist of a publisher).
I was already a fan of VM when I saw Melinda present at a SHARE conference. Hearing the history, the stories of how the system came to be, it all gave me chills. This is the system IBM tried to kill. Over and over.
The ultimate insult (to IBM) happened when Linux was ported to the mainframe. Linux works great on any platform, but is a teriffic candidate for virtualization, especially on high-redundancy hardware (like mainframes). There were two ports, by the way, one by IBM and another by Linas. No, not that Linus, and not that one either, this Linas. But that's a whole nutha story. (more intrigue!)
IBM sales guy: "Remember that system we told you to get rid of?"
IBM customer: "You mean VM? Sure. We got rid of it, like you told us."
IBM sales guy: "Well, you're gonna want it back."
IBM customer: [facepalm]
Addendum
The 1991 revision of Melinda's paper had a couple of addendums. I picked up printed copies. [remember paper?] One addendum was "Dave Tuttle's Memoirs". This is not usually seen alongside the newer revisions (of Melinda's work).
At one job, we were hosting lotso Linux on top of z/VM. (That company had never gotten rid of VM anyway.) Trying to inspire my teammates, I made copies of Tuttle's Memoirs and passed them around. [remember printed copies?] Some of the guys actually read it. These were good guys. I don't think they were in it for the money, maybe for the tech. We weren't coding, but I hope they were intrigued.
Given the myriad search engines available, you can probably find Mr. Tuttle's work for yourself. Here's one I found (other than my paper copy), starting about page 135:
http://www.cs.tufts.edu/~nr/cs257/archive/melinda-varian/neuvm.pdf
Enjoy! Be intrigued. Be inspired.
Someday I'd like to meet Dave Tuttle in person.
-- R; <><
Friday, January 17, 2014
Ho, Ho, Zero
Ho, Ho, Zero
Sir Santa tried to stuff the bag with an annual gift or two, but was late. The gifts are also a bit slim this year.
Of note, CD0, pronounced "see dee zero". This is a rootstrapping tool for NORD Linux. The slim part is that the instructions are missing. But the purpose of the thing is to supply a shell and minimal environment. When combined with GCC and BINUTILS (from CD2), the scripts at http://www.casita.net/pub/nord/build/, and a helping hand from Perl (from CD1), you can "rootstrap" a fresh system.
This rootstrapping thing (using the current CD0) has been tested on S390 and I386. The CD image also contains support for PPC, which is expected to work just fine, but is untested.
The other gift in the bag is a minor update to UFT making it leak less info in secure contexts. Seems to work just fine, but we'll have to talk about that in another post.
-- R; <><
Sir Santa tried to stuff the bag with an annual gift or two, but was late. The gifts are also a bit slim this year.
Of note, CD0, pronounced "see dee zero". This is a rootstrapping tool for NORD Linux. The slim part is that the instructions are missing. But the purpose of the thing is to supply a shell and minimal environment. When combined with GCC and BINUTILS (from CD2), the scripts at http://www.casita.net/pub/nord/build/, and a helping hand from Perl (from CD1), you can "rootstrap" a fresh system.
This rootstrapping thing (using the current CD0) has been tested on S390 and I386. The CD image also contains support for PPC, which is expected to work just fine, but is untested.
The other gift in the bag is a minor update to UFT making it leak less info in secure contexts. Seems to work just fine, but we'll have to talk about that in another post.
-- R; <><
Wednesday, January 8, 2014
Climate Change on the Net
Climate Change on the Net
There's a storm brewing. Winds of change have shaken loose the low hanging fruit and blown open the barn doors. But fruit which stays on the ground will rot and doors left open will let livestock out and predators in.
Some points to note ...
Even prior to consumer availability of IPv6, we were seeing more "things" on the internet. In my own house, when we replaced our aging Zenith television with a stylish Samsung LCD, we wound up with three "devices" on our home LAN which prior counterparts were not networked. They speak a variety of convenience protocols. Behind my firewall, they're supposedly safe. Supposedly.
Electronics in vehicles and appliances have increased and gotten steadily more sophisticated. The idiot light says "service required", so you visit your mechanic (or the auto parts store), they plug-in their OBD reader and tell you what's really wrong. Soon, your fridge will tell you to buy milk (or will order milk all by itself). Kinda scary. But also very geeky.
Cloud computing is the buzzword du jour. It's progressive in that we can buy (rent) disposable complete systems for almost any computing work imaginable. But we deploy complete package bundles, and that doesn't always scale. Default distributions are not by default secure.
So how's cloud retro?
It takes us back to the "service bureau" days.
That's not a bad thing, just ironic. It reverses the trend over several decades of owning the hardware, but it fulfills part of the MULTICS vision of computing as a utility.
A Northern Wind
NORD is a simple "open source" operating system following the standard recipe. It uses the 'make install' logic defined by individual package authors and supplements that with a ready-to-run scheme. Other than that, it's just Linux.
Unlike some Linux distributions, NORD tries to be more Unix than Linux. But it is pragmatic enough to use the Linux kernel, GNU core utilities, and other Linux packages.
The software and computing industry is increasingly distressed about security. (Privacy too, but mostly with the overall hardness against attack.) Consider a recent Wired Magazine article by Bruce Schneier (with help from Jim Gettys, I'm told) ...
The Internet of Things is Wildly Insecure
NORD is particularly suited to embedded use. (Like a generic underpinning for things like OpenWrt.) For simplicity, and giving a boost to security, it starts less services and daemons than other systems.
I use NORD daily for a variety of things, mostly related to software development. (I have a day job.) At one time, NORD's unnamed predecessor served as one of my primary internet-facing servers. It was reliable and secure.
But NORD needs help. It doesn't have an installer. That's by design, but it needs a way to bootstrap onto new hardware. Someone who can assemble a quick stamp utility for I386 and S390 would really be welcome.
An old reference doc for NORD is in Google space ...
NORD Scratch Linux
Recently, friends familiar with the project have lent a hand, one in particular. Their contributions are huge, breaking NORD out of the "one man's toy" mode into something reproducible. Thanks.
NORD is not the only source based system available. If more people, especially the civic minded hacker brain trust, would use systems like LFS, the digital world would be better overall.
There's a companion project, not so much help on the systems front but a boost to security. UFT (Unsolicited File Transfer) has gotten new attention. While its original design was more for interoperability than privacy, it turns out to be great for both goals.
Join the movement.
-- R; <><
There's a storm brewing. Winds of change have shaken loose the low hanging fruit and blown open the barn doors. But fruit which stays on the ground will rot and doors left open will let livestock out and predators in.
Some points to note ...
- IPv6, enabling "the internet of things"
- pervasive embedded computing (not your father's Oldsmobile)
- cloud computing, futuristic and retro
Even prior to consumer availability of IPv6, we were seeing more "things" on the internet. In my own house, when we replaced our aging Zenith television with a stylish Samsung LCD, we wound up with three "devices" on our home LAN which prior counterparts were not networked. They speak a variety of convenience protocols. Behind my firewall, they're supposedly safe. Supposedly.
Electronics in vehicles and appliances have increased and gotten steadily more sophisticated. The idiot light says "service required", so you visit your mechanic (or the auto parts store), they plug-in their OBD reader and tell you what's really wrong. Soon, your fridge will tell you to buy milk (or will order milk all by itself). Kinda scary. But also very geeky.
Cloud computing is the buzzword du jour. It's progressive in that we can buy (rent) disposable complete systems for almost any computing work imaginable. But we deploy complete package bundles, and that doesn't always scale. Default distributions are not by default secure.
So how's cloud retro?
It takes us back to the "service bureau" days.
That's not a bad thing, just ironic. It reverses the trend over several decades of owning the hardware, but it fulfills part of the MULTICS vision of computing as a utility.
A Northern Wind
NORD is a simple "open source" operating system following the standard recipe. It uses the 'make install' logic defined by individual package authors and supplements that with a ready-to-run scheme. Other than that, it's just Linux.
Unlike some Linux distributions, NORD tries to be more Unix than Linux. But it is pragmatic enough to use the Linux kernel, GNU core utilities, and other Linux packages.
The software and computing industry is increasingly distressed about security. (Privacy too, but mostly with the overall hardness against attack.) Consider a recent Wired Magazine article by Bruce Schneier (with help from Jim Gettys, I'm told) ...
The Internet of Things is Wildly Insecure
NORD is particularly suited to embedded use. (Like a generic underpinning for things like OpenWrt.) For simplicity, and giving a boost to security, it starts less services and daemons than other systems.
I use NORD daily for a variety of things, mostly related to software development. (I have a day job.) At one time, NORD's unnamed predecessor served as one of my primary internet-facing servers. It was reliable and secure.
But NORD needs help. It doesn't have an installer. That's by design, but it needs a way to bootstrap onto new hardware. Someone who can assemble a quick stamp utility for I386 and S390 would really be welcome.
An old reference doc for NORD is in Google space ...
NORD Scratch Linux
Recently, friends familiar with the project have lent a hand, one in particular. Their contributions are huge, breaking NORD out of the "one man's toy" mode into something reproducible. Thanks.
NORD is not the only source based system available. If more people, especially the civic minded hacker brain trust, would use systems like LFS, the digital world would be better overall.
There's a companion project, not so much help on the systems front but a boost to security. UFT (Unsolicited File Transfer) has gotten new attention. While its original design was more for interoperability than privacy, it turns out to be great for both goals.
Join the movement.
-- R; <><
 |
| NORD Mascot |
Subscribe to:
Posts (Atom)