2 ms·

Yeah, I'm intimately familiar with the environmental requirements of that era of CDC drives because in 1980 I started a student run computer center with the Log

by hga 12y ago

Yeah, I'm intimately familiar with the environmental requirements of that era of CDC drives because in 1980 I started a student run computer center with the Logo Lab's surplus PDP-11/45, and managed to snag the above mentioned CDC drive and controller. We put it in a MIT Building 20 room with just comfort AC (which had a tendency to freeze up, humans produce water vapor that computers don't, so a system to detect that and give a unit a time out was built), and aside from occasionally blowing a power transistor for the big solenoid that moved the heads it ran like a champ. The best at hardware student I attracted showed me how he diagnosed this, by simply pushing the solenoid's outer coil in both directions and seeing which failed to resist. Since we had almost no money at the time, he was generally able pop the top off the transistor and reattach a failed lead (I guess vibration was the cause of those failures). As for VC investing, if it didn't mention the formula of how many buyers a company's product might serve and the value to them, which of course produces a very high possible value for a lot of biomedical firms as you note ... bleah. If current VCs don't want to play this game, which I was told was part of it during e.g. the '80s, it's indeed an opportunity. Although I'd say developing software is seldom truly low risk, most people just don't understand how difficult this can be (it's a people problem).

graycat 12y ago
> Although I'd say developing software is seldom truly low risk, most people just don't understand how difficult this can be (it's a people problem). Yes, there's a long history of too long delayed or failed software projects. One way and another, mostly I've managed to avoid such projects. My experience has been that software projects are fast, fun, easy, routine, and low risk. But, currently I have encountered an exception: My current project involves my bringing up a Web site, and, for whatever the balance of reasons were, I decided to build on Windows. I'm writing in Visual Basic .NET -- apparently essentially equivalent to C# but with a different flavor of syntactic sugar that I like better than the deliberately idiosyncratic syntax of C borrowed by C#. The Visual Basic .NET has been fine -- really nice. And how it works in developing Web pages is even nicer. And I just keep typing into my favorite text editor, where I have 100+ macros and can easily write more, and don't try to make use of Visual Studio. But the problems are: (1) Documentation of the many classes I needed to use in the .NET Framework, ASP.NET (for the Web pages), and ADO.NET (for using SQL Server), (2) software installation, (3) more in system administration, and (4) system security. The part of the software development uniquely mine has remained fast, fun, easy, routine, and low risk. E.g., once it was a week of mud wrestling just to get a connection string that worked between one of my Web pages in Visual Basic and SQL Server. The documentation was clear as mud, and I just had to throw guesses out until one stuck. A virus wiped out essentially all of my installation, and I had to reinstall the OS and all the software starting again with an empty boot partition. Then the reinstall of SQL Server messed up, and I had to start again, with an empty boot partition. Then I tried to get SQL Server to use my old database, and SQL Server got sick; I tried to reinstall SQL Server, and Windows got sick, and I had to reinstall everything to an empty boot partition again. I decided to back up the boot partition using NTBACKUP, and when I needed the back up copy, the restored copy didn't boot. So, right, I had to reinstall everything to an empty boot partition, again. This was getting old. Why did the restore not boot? Secret #119,385,232,345: When back up a boot partition with NTBACKUP and want the result, if restored, bootable, then have to request "do save system state". What the heck was system state, my options for Outlook? Of course, the documentation never said, never gave any discussion, etc. So, all there was was a check box. Thanks a lot, guys. Nope, "system state" is much more important than my options for Outlook, as I eventually discovered largely by accident from looking at the log files from a save of my boot partition with WinZip. So, to be able to use NTBACKUP, which actually has some amazing functionality if can get it to work, I ran experiments, installed Windows, backed up with NTBACKUP, tried a restore, which failed, tried again, and kept up this work for days before I got it all working well. Then I documented it, the whole thing, click by click, keystroke by keystroke. Now if my boot drive gets sick for any reason, I can boot Windows from another bootable partition and restore my main partition. And I can back up my bootable partition with NTBACKUP easily, routinely, in less than an hour, any day at lunch. I found, downloaded, read, studied, saved, indexed, and abstracted 5000+ Web pages of documentation, nearly all from MSDN. That was a lot of work. Plus more work for documentation of SQL Server. For SQL Server, even for some basic, simple things, I couldn't make sense out of the Microsoft documentation. And for their SQL Server Management Studio, eventually I saw how to use it usefully for just browsing but never saw how to use it for actual SQL Server management -- it's awash in check boxes, panels, and windows I have no idea what the heck they do if anything or anything useful. So for management of SQL Server, I used just standard, vanilla SQL commands as documented by other than Microsoft. So, eventually I was able to get by the issues of users, logins, passwords, the SQL Server versions of capabilities and access control lists, databases, etc. For using TCP/IP on Windows, I could make no sense out of most of the Microsoft documentation so just returned to some old documentation of TCP/IP and some old sample code of mine, saw again what the basic API functions were, guessed what Microsoft had as the equivalent, and got some TCP/IP working between some servers. It went on this way: Documentation, installation, management, and security -- mud wrestling. It cost me years, a big chunk of my life, a WMD to my finances, where all the while the part of the software uniquely mine was fast, fun, easy, routine, low risk. But apparently now I'm past much of that mud wrestling with documentation. Security? Just spent the past six weeks (outrageous) getting rid of a virus I picked up from somewhere, maybe Flash (they keep saying that their software is a security risk). The Microsoft virus scanning tools, which I ran for days, didn't fix the virus. Eventually a System Restore back to two months earlier did. What other people do about these issues I don't know. My part? Fast, fun, easy, routine, low risk. My Web site architecture has several back end software servers communicating via TCP/IP. The architecture is all nicely scalable just via simple sharding. E.g., I wrote my own Web site session state server, just as a key-value store, using just TCP/IP sockets, class instance de/serialization, and two collection classes. Fast, fun, easy, and the code is blindingly fast -- from my timings a server costing less than $1000 in parts should be able to do the session state put and get work for sending 5000+ Web pages a second, and simple sharding could increase that by a factor of 100. Easy. Fun. Some of my servers are doing, say, an exploitation of the Hahn-Banach theorem in a Hilbert space. Not trivial. And, yes, have to expect that at some point will need some numerical linear algebra. So, I downloaded the Fortran version of LINPACK, used the utility f2c (translate Fortran to C), compiled the C code, tested it, worked fine, and used Microsoft's platform invoke to call the C code. Did lots of testing and timing -- it works fine. I needed a couple of fast, cute algorithms, invented them, programmed, tested, timed, and documented them -- they work fine. For my SQL Server schema (that is, the tables, columns, and other properties, that is, not what Microsoft's SQL Server Management Studio calls a schema), SQL was fast, fun, and easy. Heck, long ago in a few days eating dinner at the Mount Kisco Diner while reading Ullman's book on database and SQL, I got it on the language, right away. So, for my project, in about two hours, fun, easy, I wrote out, with soft pencil, my schema for what my project needs now and for much more in the future, typed in the schema, and it's been fine ever since. I have enough keys, etc. to make everything really fast without any joins. Simple. Fun. Right, so far I should be able to get by with just a key-value store, but RDBMS still has some advantages if I can get through the documentation actually to make the advantages work. Here I anticipate a lot of mud wrestling and/or some really good technical support. Looks like I will have to set up a computer on the side and use it just to practice installs, backup, restores, etc., over and over and over, finally document what actually works. Then use system management automation means to automate that work. There's an old statement about some of IBM's software: "If you just follow the documentation for how to do the installs, then I will guarantee you it won't work." SQL Server installation, documentation, and administration -- barbed wire enema. My part's easy. For working through Microsoft's part, maybe I'm past that.
- hga 12y ago
  "What other people do about these issues I don't know." Work in a shop that's acquired a lot of Microsoft knowledge. With a very distrusting attitude. The last major MS ecosystem project I worked on was with a big MS fan, during his college summers he'd worked on Internet Explorer back when it was getting to be much better than Netscape. And turned down a full time offer from them for more of the same to work on his brother's company. But circa 1997 he was not willing to trust SQL Server as it was then with the company's fate when it was time to move from the superb Access Jet database engine, and I suggested and implemented IBM's DB2 as a 1/2 price alternative to Oracle (biggest issue was no MVCC, but that was OK for a tight knit group of programmers; the sysadmin and DBA job was in turn easier than Oracle's long evolved mess). Fortunately never had to go back after that, and prior to that I learned Windows 3.0 though NT 3.51 the hard way, back when that wasn't a nightmare. NT 3.51 SP2 or so was when it started going to hell). I made Windows GUIs work by starting with a sample program that worked, and carefully mutating and checking for viability each step. Used SoftICE to debug the hard stuff. Built a stunningly good system using Microsoft's implementation of DCE RPC (the alternative to Sun's haphazard stuff). But as I note the stuff outside of my code kept getting better and better. Oh, did I say in that last job that MS's Visual C++ STL library wasn't thread safe? On a naively multi-threaded system, that I used with 2 CPUs until 2002? Bleah. You've learned a lot of stuff, but the price sounds like it's too high unless you're going to continue in this ecosystem, and I'm advising all my friends to leave it. Especially with the new CEO, who very possibly has serious damaged its existing QA system without replacing it with something better (rather like one of the causes of the 2nd part of the Vista nightmare). And, yeah, SQL is GREAT. Just helped a friend with a project using PostgreSQL ... and its doc is great, like IBM's for Windows and UNIX(TM) back then, and Oracle's in the 1994-2001 time frame. Get some books by the greats, like C.J. Date, and you will have oodles of fun.

by hga 12y ago

graycat 12y ago

> Although I'd say developing software is seldom truly low risk, most people just don't understand how difficult this can be (it's a people problem). Yes, there's a long history of too long delayed or failed software projects. One way and another, mostly I've managed to avoid such projects. My experience has been that software projects are fast, fun, easy, routine, and low risk. But, currently I have encountered an exception: My current project involves my bringing up a Web site, and, for whatever the balance of reasons were, I decided to build on Windows. I'm writing in Visual Basic .NET -- apparently essentially equivalent to C# but with a different flavor of syntactic sugar that I like better than the deliberately idiosyncratic syntax of C borrowed by C#. The Visual Basic .NET has been fine -- really nice. And how it works in developing Web pages is even nicer. And I just keep typing into my favorite text editor, where I have 100+ macros and can easily write more, and don't try to make use of Visual Studio. But the problems are: (1) Documentation of the many classes I needed to use in the .NET Framework, ASP.NET (for the Web pages), and ADO.NET (for using SQL Server), (2) software installation, (3) more in system administration, and (4) system security. The part of the software development uniquely mine has remained fast, fun, easy, routine, and low risk. E.g., once it was a week of mud wrestling just to get a connection string that worked between one of my Web pages in Visual Basic and SQL Server. The documentation was clear as mud, and I just had to throw guesses out until one stuck. A virus wiped out essentially all of my installation, and I had to reinstall the OS and all the software starting again with an empty boot partition. Then the reinstall of SQL Server messed up, and I had to start again, with an empty boot partition. Then I tried to get SQL Server to use my old database, and SQL Server got sick; I tried to reinstall SQL Server, and Windows got sick, and I had to reinstall everything to an empty boot partition again. I decided to back up the boot partition using NTBACKUP, and when I needed the back up copy, the restored copy didn't boot. So, right, I had to reinstall everything to an empty boot partition, again. This was getting old. Why did the restore not boot? Secret #119,385,232,345: When back up a boot partition with NTBACKUP and want the result, if restored, bootable, then have to request "do save system state". What the heck was system state, my options for Outlook? Of course, the documentation never said, never gave any discussion, etc. So, all there was was a check box. Thanks a lot, guys. Nope, "system state" is much more important than my options for Outlook, as I eventually discovered largely by accident from looking at the log files from a save of my boot partition with WinZip. So, to be able to use NTBACKUP, which actually has some amazing functionality if can get it to work, I ran experiments, installed Windows, backed up with NTBACKUP, tried a restore, which failed, tried again, and kept up this work for days before I got it all working well. Then I documented it, the whole thing, click by click, keystroke by keystroke. Now if my boot drive gets sick for any reason, I can boot Windows from another bootable partition and restore my main partition. And I can back up my bootable partition with NTBACKUP easily, routinely, in less than an hour, any day at lunch. I found, downloaded, read, studied, saved, indexed, and abstracted 5000+ Web pages of documentation, nearly all from MSDN. That was a lot of work. Plus more work for documentation of SQL Server. For SQL Server, even for some basic, simple things, I couldn't make sense out of the Microsoft documentation. And for their SQL Server Management Studio, eventually I saw how to use it usefully for just browsing but never saw how to use it for actual SQL Server management -- it's awash in check boxes, panels, and windows I have no idea what the heck they do if anything or anything useful. So for management of SQL Server, I used just standard, vanilla SQL commands as documented by other than Microsoft. So, eventually I was able to get by the issues of users, logins, passwords, the SQL Server versions of capabilities and access control lists, databases, etc. For using TCP/IP on Windows, I could make no sense out of most of the Microsoft documentation so just returned to some old documentation of TCP/IP and some old sample code of mine, saw again what the basic API functions were, guessed what Microsoft had as the equivalent, and got some TCP/IP working between some servers. It went on this way: Documentation, installation, management, and security -- mud wrestling. It cost me years, a big chunk of my life, a WMD to my finances, where all the while the part of the software uniquely mine was fast, fun, easy, routine, low risk. But apparently now I'm past much of that mud wrestling with documentation. Security? Just spent the past six weeks (outrageous) getting rid of a virus I picked up from somewhere, maybe Flash (they keep saying that their software is a security risk). The Microsoft virus scanning tools, which I ran for days, didn't fix the virus. Eventually a System Restore back to two months earlier did. What other people do about these issues I don't know. My part? Fast, fun, easy, routine, low risk. My Web site architecture has several back end software servers communicating via TCP/IP. The architecture is all nicely scalable just via simple sharding. E.g., I wrote my own Web site session state server, just as a key-value store, using just TCP/IP sockets, class instance de/serialization, and two collection classes. Fast, fun, easy, and the code is blindingly fast -- from my timings a server costing less than $1000 in parts should be able to do the session state put and get work for sending 5000+ Web pages a second, and simple sharding could increase that by a factor of 100. Easy. Fun. Some of my servers are doing, say, an exploitation of the Hahn-Banach theorem in a Hilbert space. Not trivial. And, yes, have to expect that at some point will need some numerical linear algebra. So, I downloaded the Fortran version of LINPACK, used the utility f2c (translate Fortran to C), compiled the C code, tested it, worked fine, and used Microsoft's platform invoke to call the C code. Did lots of testing and timing -- it works fine. I needed a couple of fast, cute algorithms, invented them, programmed, tested, timed, and documented them -- they work fine. For my SQL Server schema (that is, the tables, columns, and other properties, that is, not what Microsoft's SQL Server Management Studio calls a schema), SQL was fast, fun, and easy. Heck, long ago in a few days eating dinner at the Mount Kisco Diner while reading Ullman's book on database and SQL, I got it on the language, right away. So, for my project, in about two hours, fun, easy, I wrote out, with soft pencil, my schema for what my project needs now and for much more in the future, typed in the schema, and it's been fine ever since. I have enough keys, etc. to make everything really fast without any joins. Simple. Fun. Right, so far I should be able to get by with just a key-value store, but RDBMS still has some advantages if I can get through the documentation actually to make the advantages work. Here I anticipate a lot of mud wrestling and/or some really good technical support. Looks like I will have to set up a computer on the side and use it just to practice installs, backup, restores, etc., over and over and over, finally document what actually works. Then use system management automation means to automate that work. There's an old statement about some of IBM's software: "If you just follow the documentation for how to do the installs, then I will guarantee you it won't work." SQL Server installation, documentation, and administration -- barbed wire enema. My part's easy. For working through Microsoft's part, maybe I'm past that.

hga 12y ago
"What other people do about these issues I don't know." Work in a shop that's acquired a lot of Microsoft knowledge. With a very distrusting attitude. The last major MS ecosystem project I worked on was with a big MS fan, during his college summers he'd worked on Internet Explorer back when it was getting to be much better than Netscape. And turned down a full time offer from them for more of the same to work on his brother's company. But circa 1997 he was not willing to trust SQL Server as it was then with the company's fate when it was time to move from the superb Access Jet database engine, and I suggested and implemented IBM's DB2 as a 1/2 price alternative to Oracle (biggest issue was no MVCC, but that was OK for a tight knit group of programmers; the sysadmin and DBA job was in turn easier than Oracle's long evolved mess). Fortunately never had to go back after that, and prior to that I learned Windows 3.0 though NT 3.51 the hard way, back when that wasn't a nightmare. NT 3.51 SP2 or so was when it started going to hell). I made Windows GUIs work by starting with a sample program that worked, and carefully mutating and checking for viability each step. Used SoftICE to debug the hard stuff. Built a stunningly good system using Microsoft's implementation of DCE RPC (the alternative to Sun's haphazard stuff). But as I note the stuff outside of my code kept getting better and better. Oh, did I say in that last job that MS's Visual C++ STL library wasn't thread safe? On a naively multi-threaded system, that I used with 2 CPUs until 2002? Bleah. You've learned a lot of stuff, but the price sounds like it's too high unless you're going to continue in this ecosystem, and I'm advising all my friends to leave it. Especially with the new CEO, who very possibly has serious damaged its existing QA system without replacing it with something better (rather like one of the causes of the 2nd part of the Vista nightmare). And, yeah, SQL is GREAT. Just helped a friend with a project using PostgreSQL ... and its doc is great, like IBM's for Windows and UNIX(TM) back then, and Oracle's in the 1994-2001 time frame. Get some books by the greats, like C.J. Date, and you will have oodles of fun.