100% agree - for years
100% agree - for years
As a computer programmer I tended first to think of my own failings, and then failings I've found on Slashdot and other IT kind of places. Really interesting fallacies, takes some actual critical thinking to get clear on how folks goof up.
But WOAH! I forgot about Facebook - OMG, how much unpleasantness goes on for the little local zip code pages! Just let one jerk initiate an ad-hominem targeting some regular village resident, and wow, do the other jerks pop out of nowhere to join in slinging the crap! I had to change my vote to bandwagon. No brains required to analyze the fallacies found on FB..
While reviewing the online repository for the stethoscope design, I saw that mainly it's the sound gathering part that is 3D printed. The rest is - reasonably - made out of regular stuff. So then, with some regular stuff, can't local people figure out how to make stethoscopes? They really can't figure out that one sound gathering piece? It takes a doctor/hacker to come from some land far away bearing the URL to a 3D printable part to solve the problem?
Forth is a straight-up imperative language. It's a procedural postfix notation. The environment is very interactive, you've got your hands right into the language mechanics when you use Forth.
What I love about Forth is the tradition of small routines. I think programming in any language benefits from using very small routines. When building a Forth program, there is a tradition of getting into higher level programming quickly - write leaf routines to do the low level bit twiddling nitty-gritty, test them interactively. Then start building the program by assembling those together into higher level pieces. Also you can run Forth almost anywhere, if you look around the web for an implementation.
What I hate about Forth is for the leaf routines it's very much like writing in some complicated assembly language.
Perhaps I should clarify, I mis-stated the situation a little: You can "read-only" examine a file without checking it out. (We were using Excel.) In that case there is a check-out button that shows when the document is open. If you try to press the button and someone else has it out, true, you can't. But then they check in. THEN you can check it out with the button. In that case you are still looking at the file you "read-only" loaded, but now you can edit it. Then you can check it in. During that process, you did not receive the OTHER check-in, and you wipe it out.
This happened to us a lot. Like I said, we were using Excel. It might be that other tools like Word might update the file when you check it out, but Excel surely does not.
My experience with SharePoint: A) it does not protect against multiple check-outs followed by multiple check-ins erasing other people's changes. Basically there's no detection of collisions between your changes and changes since you checked out. This caused a lot of grief in my work group. B) The versioning is strictly linear, at least I never saw any branching. That is very unlikely to address business needs. So you will need a naming scheme to represent branches.
I know this will hit my karma, but here goes..
I'd ask Wolfram: Why do you say Alpha is so great. I understand it's hard. So then be clear about what it's good at. Why do you represent as if it's some all knowing AI when it goes to crap for any question that any self respecting SciFi fan would ask first?
It does really, really well with the examples that Wolfram uses in his introductory video. I get great results when I ask a stock market question, sure. I also get great stock market analysis results from Yahoo, Google, and e*Trade. In response to every other question I ask it I get crap. It typically has little data on my areas of interest, so it seems to dumb down the parse on my question to make a search *for* crap. So then it returns crap. Charted in one or two ways.
I want to ask things that would help me pilot a space ship, or at least help me understand NASA's proposals to the U.S. Congress. For instance, "How do I plot a course from earth to Uranus?" I just this moment typed that in, and guess what - complete crap. It returned a plot of x^2, and nary a mention of gravity or planets or time anything else. How did it manage to parse a question about a course from Earth to Uranus and decide x^2 was the best item to present?
Look what it says about its parse of my question: "Using closest Wolfram|Alpha interpretation: how do I plot a". What? "How do I plot a"? I did type a subject, folks! It didn't even try to get to the planets, orbits, gravity, anything. IT DIDN'T EVEN TRY! I see that if there are no knowledge frames in the system pertaining to my query, it seems likely to chop down the input. I'm learning more about how Alpha is implemented than I am learning about my query!!
Can't it at least show any historical paths that spacecraft have used between the planets? Can't it even show the planets? Can't it even cite procedural texts on how to do it? Can't it mention some of the factors that must be considered? I would like the result from an all-knowing AI to be an applet that shows a spaghetti line stretching out among the bodies of the solar system, and I would like to be able to adjust the launch date and see the planets move and see what happens to the spaghetti line.
BTW, that little Game of Life CA that displays while I'm waiting for my answer. Ha ha. I guess that's so cool. I confess, it does make me feel that some really thoughtful process is going on, just what marketing wants. For all that, what comes back - crap. Just makes it all the more disappointing.
This process does allow senators to go on record with their specific belief positions about climate change.. the details there are interesting.
Actually, the PDP-11 instruction set *IS* the basis of 80386 CISC - even though PDP-11 style is not a basis of 8086, 80186 CISC. Check it you & you'll notice the 80386 designers flipped head over heels and every which way they could to give the 386 the programmer architecture of the PDP-11. The instruction word structure is not as beautiful - but they tried like hell to achieve an assembly level presentation that matched.
If you compare PDP-11 assembly with 80386 assembly, nothing special - because with the 80386 Intel *FINALLY* got over to the IBM360 style orthogonal instruction set that the PDP-11, VAX-11, Motorola 68000 had implemented for years. If you look at the Intel 8080, 8086, 80186, 80286 instruction sets, you'll see a mucked up bucket of junk. That goes for lots of other micros and minis from the era, too. Back then it was easy to sacrafice the instruction set to save registers and control logic - there was an historical thread of minimal logic CPUs with crappy instruction sets. But there was also a thread of beautiful orthogonal instruction sets comming out of the late 1950's and the 1960's, exemplified finally by the IBM360. The PDP series contributed a lot of orthogonality in this period, too, but the 360 was 32 bits while the other orthogonal PDP's were 18 and 36 bits. The PDP-11 was a power of 2 bit width, half the 360's, and came out looking a heck of a lot like the 360.
DEC made a sample of the mucked up variety as well - check out the PDP-8.
PS - yes, I know the PDP-11 is 16 bit, while the 360 and 68000 are 32 bit - I meant to refer to the "orthogonality" of the instruction sets, and structure of the instruction words, rather than the bit widths when I made the comparisons above...
Note, too, that the IBM 360 instruction set is 32 bit and highly orthogonal, very much as is the PDP-11, and later the Motorola 68000, in fact the 360 instruction set pre-dates the PDP-11 by several years.. Both DEC and IBM were heading in the same direction over some of the same years that way. It's hard to really claim that DEC (Gordon Bell) copied IBM there, but it's also really hard to claim he didn't.
This article did not discuss the reorganization plans. Instead it whined and complained about Microsoft's poor sales performance.
Article by a professor who took the course along with a small group:
1) RMS himself clarifies at least his intent in developing a (free as in freedom, free as in beer) OS & tools for everyone differentiates between widely empowering technology like OSes, compilers, and printer drivers versus specialized applications with few users. He points out that if the ecosystem is small, then proprietary relationships may be necessary and therefore appropriate. (Sorry no time to dig out the quote, but its in his stuff on the FSF site.) The question is what will be better for common good, so consider size of the user community, business models, etc. A kind but proprietary business with good practices that survives -> is better than an over-idealistic business that fails -> is better than a mean business with selfish intentions and bad practices that enlists and then controls customers.
2) Are the benefits of going public and free worthwhile against the loss of proprietary value? If your company will make larger revenue because your competitors have adopted your software, then go for it. That means the driver of your revenue has more to do with your business activities like selling, integrating, servicing, designing solutions. For example, if being able to integrate your equipment easily with your competitors means you make more money. But if you rely on the performance/capabilities of your software to drive revenue, then keep it closed until your business has grown up to become more service oriented.
3) Don't expect your competitors to play fair with the free software they pick up. They're not going to contribute back as they should. They might not admit they are using the software.
4) You don't need to go public with your free software yourself. Your question was w/respect to the community, so maybe this point is not relevant. Customers should be looking for free software in case a) you fold & no longer service their maintenance needs; b) they wish to take development on a different tack, they should be able to start with your product as a basis; c) they want remarketing rights, etc. But just because you sell them free software doesn't mean they intend to remarket or even give it out to anybody else, though they have the right. As to these customer needs, you may be able to come to an informal understanding that is mutually beneficial, or you may provide for the specific rights they wish in a specific license for them instead of making the software fully free.
"Aww, if you make me cry anymore, you'll fog up my helmet." -- "Visionaries" cartoon