What compiler was used? (that would be GNU C, C++) What linker... I'll wait... (that would be GNU ld) In general, GNU bintools. What editor? was it emacs? (it could have been vi, or vim). But, if you use emacs... What shell? Bash. GNU again.
As to the "ogg" -- mpeg-2 patents: http://www.mpegla.com/m2/m2-agreement.cfm mpeg-1 uses mp3 audio, which is patented. Heck, even fedora doesn't play it! AVI? Its a fucking minefield (I REALLY don't have the time to post the patents involved -- fortunately a lot of the companies involved are dead, or don't care -- allowing us to play these formats with x86 shims).
GNU means ONLY open, which means... ogg. Get over it. The FSF would make no other choice.
The GPU is (generally) a vector processor with VERY limited branching capability, and VERY limited data sourcing. But, these things can be "fixed".
Yes, Intel is working on an "x86 GPU".
"Larrabee can be considered a hybrid between a multi-core CPU and a GPU, and has similarities to both. Its coherent cache hierarchy and x86 architecture compatibility are CPU-like, while its wide SIMD vector units and texture sampling hardware are GPU-like." (from http://en.wikipedia.org/wiki/Larrabee_(GPU) )
As to Cg being "open sourced"? Nope, it is available, but the ISA of the nVidia chip is still closed. If I *could* I would work a vector/flow backend compiler for (a subset of) scheme to support it. But I can't. I will be able to with LARRABEE. I would probably base a compiler on Marc Feeleys picoscheme work. But... well, I can't.
How is a "GPU" different from a "CPU"? If you take them to be the SAME, you end up with Intels LARRABEE. If you take them as somehow DIFFERENT, you end up with nVidias proclamation.
If they are considered the SAME, but with different performance tunings, other applications begin to open up.
As an example: it is currently true that the "GPU" is given an exorbitant amount of resources to do one thing -- create visuals for games.
And that's it. It contains a significant amount of the system memory, and processing logic, and "locks it away". Which is very good if you are selling the graphics cards, but not ideal (at all) for the customer.
If the graphics card can be placed closer and more generally, the customer would win. EXCEPT -- for one problem (and, boy is it a doozy).
The nVidia is programmed with a specific higher-order assembly language, We rely solely on the hardware vendor for tools. I think that this is UNIQUE in the (mass-market) processor world. And this is why Intel, with an x86 compatible GPU is such a threat. Can anyone else produce an OpenGL shader compiler for the nVidia? Or, better yet, extend it to do NON-shader tasks. How about for the AMD? Yes, you CAN for Intel, and will, by design be able to (I would expect, even ENCOURAGED) for LARRABEE.
The idea is to extend the "NUMA" concept for memory to processors. Intel is doing it because others are already doing it - SUN with Niagra and Niagra 2 are providing an absolutely amazing proof of concept. (except with multi-core and FPU units).
Why would you BOTHER with a specific purpose GPU, if you could have a (possibly less performant) workable solution with more cores, AND be able to use them for other tasks?
Of course this is not particularly relevant to TODAYs applications. They are matched to current hardware. Now, I will bring up the L word - Linux. Linux is suited to a much wider degree of scaling (practically) and runs on ARM up to Z/Series. It also supports NON-x86 ISAs. Which would mean that a non-x86 version of this idea is probably supportable. But, it wouldn't run CURRENT software, and, I believe, would be a complete non-starter.
But, take this with a grain of salt -- I am obviously not a great predictor (otherwise I would already be retired).
So, I guess "TS" doesn't standard for "Transport Stream", and there aren't any PTS (Presentation Time Stamps)... Oh crap, I guess MPEG doesn't come from satellites after all:(
And, I guess the small TS stream packet sizes and inclusion of I-Frames doesn't allow you to just jump on a stream at any time! More sadness:(
Who in their right mind CARES? You pick a well-supported standard format: Um... let's see, MPEG, XVID, VIDX, AVI container, MPEG container, MP3 sound, AC3 sound, whatever... and put the video up.
What? They didn't do that? They picked a new format for some reason; one that requires a platform refresh, and unholy amount of effort. Didn't even use (gasp) FLASH video?
Why on Earth would anyone do that?
The only 'splaining here is why a Political Party that will (most likely) be running the most powerful country on the planet is actually allowed to get a rim-job from a private company. Not that *I* could care -- but that is pushing the classic boundary commonly known a facist. Along with the rim-jobs the US gov' received from terrestrial radio, And etc.
Oh -- I here you saying "But the Dems didn't get a rim-job from Microsoft! They did it by themselves!" In which case, I think it's worse -- they SHOULD have held out for lots of plums before forcing that move.
Me? I don't care; enjoy yourselves!
Vote Democrat! Vote Microsoft! Vote Republican! Vote Microsoft! Just be sure to Vote!
How does ssh do it? Easy. The FIRST time it says that you have never used this system, and would you like to accept it. If the key EVER changes, you are "thrown out" by default. Bad error!
Works for ssh... Now I COULD tell my users to tunnel http through ssh instead of using https: but (and this is funny), SSL with FF3 works the same as ssh (key info change == bad error). So, why the (irrational) initial dialogs?
As to the http tunnel -- it would work (for some measure of work) BUT if ssh is not available, the temptation would be to simply use http. Which is bad (VERY BAD). So, I would never enable it. Instead, I vector access to the https pages via an http page, that contains details as to what to expect. Problem "solved".
Anyway, I was commenting on the GPs idea that somehow self-signed certificates result in a communication that is "less secure". Which is just plain wrong.
"it is security at a much higher level than using a self-signed crutch"
Explain please. Exactly how is it more secure? Clue: the signing has NOTHING to do with the security.
I personally don't have issues with security and my (personal) web sites. I do have issues with running a plaintext connection. Indeed I know who I am, and I would like to have private conversations with myself (as it were). An example is my wiki -- closed access (well, open to 5 people on the planet). Uses SSL, to avoid snooping of user/password and even the CONTENTS of the messages. I don't trust CAs, and, for this application don't need to trust a CA. Actually, my SECURITY for this wiki is better than a "signed CA" -- simply by remaining self-signed.
I guess that C++ could (in a demented way) be viewed as a functional language. I imagine that template expansion could be viewed as functional programming (assuming your compiler doesn't blow up) to implement this at compile time.
Please expand: C++ is a functional language? Can you actually code without (imperative) assignment?
C++ is an OOP language? Can objects be completely isolated?
And WHY would "smart pointers" be needed in a functional language anyway? Or even in an OOP language. Isn't the point of EITHER of these paradigms to eliminate that need?
For 32KB systems, I would recommend either absolute assembler, or program conversion - higher order to lower order (subset Scheme to assembler, and possibly TinyScheme). Even C is excessive, but possible. C++? Unless you have absolute control on template production, I would doubt it.
Simply because using the STL and making a SINGLE type change can result in inclusion of thousands of bytes of code (as the templates instantiate). Example: modify a short vector to a long int vector on the platform. The machine code will now have to include math libraries, and all the overhead of instantiating. Easily 30KB, which then blows out your 16KB deliverable.
And, it isn't possible to put source level checks in place to prevent this.
Yes, C is a "high level" assembler (low level language), but is better suited for this type of development. Now, the code being targeted at this platform typically DOES NOT HAVE TO BE PORTABLE. Normally, every byte has to be accounted for anyway, making absolute assembler very practical. None of the higher order C++ constructs are useful, because abstraction is simply not a consideration on these platforms. C is useful, because it is easier than learning yet another assembler. Scheme can be useful, because it is easy to generate a subset compiler yourself to the target platform. (more people can do the Scheme, than can successfully generate a C compiler).
Back to "portability": In this space the following code would make a lot of sense, and is considered "portable"
#define BASE 0x7000 #define STATUS (BASE+1) #define READY 0x0001 #define NOTHING... char *status = (char *)STATUS; while ((*status & READY) == 0)
NOTHING;...
(but there is no timeout implemented, this was just an example).
My CV in this area: biometers, micro-controllers (SCSI, other), heads-up displays, etc. And with ALL systems in the 64KB and less capacity, I have NEVER been asked to do C++. Nor have I ever recommended it. I would be curious if there have been success stories in this particular space.
Of course the customer isn't my property. I am simply stating that putting in place service requirements can be good for the customer (they know what they are getting), and good for the providers (it stabilizes the market).
It already happens in other industries (taxi, medical, etc.). FYI - why is accreditation required to deliver the results of a medical instrument, and yet NOT required when programming the same instrument? Even when we know that some medical instruments have killed patients.
Any platform that has a C compiler can run Gambit-C (Python is in the same "class"). Of course, some platforms may be... to anemic to support Scheme. But, the proof in the pudding is TinyScheme, and LispMe (TinyScheme is a very small, VERY portable implementation of a Scheme interpreter, and LispMe is a Scheme implementation on a 68000 Palm platform).
Python is ALSO available on the 68000 (Palm) -- Pippy is the name of the implementation.
So, for some data points - both Scheme and Python have at least one (for reference) implementation on the 68000. I am not sure if I can pull this back to 16 bit addressable platforms (z80 et al) or 20 bit platforms (8086). But this doesn't really matter these days.
Indeed, even SNOBOL4 from the 60's is portable -- now that we have a reference C implementation (SNOBOL-C). This implementation implements the macro base in C, making it portable to machines with a sufficient address space. All of these systems (Scheme, Python, Snobol4) run on 32 bit x86 little-endian Linux, and 64 bit Sparc big-endian Solaris. Portable enough?
Now, C++ is "tricky" to get right. The compiler needs to be almost insanely well-done in order to optimize. It is VERY hard to be introspective on code (C++ = practically impossible, without actually implementing the compiler, Python = merely hard, SNOBOL4 = easy, but a bit weird, Scheme = easy, bordering on trivial).
It is almost impossible to look at C++ code in isolation, and determine what it does, let alone if it is correct. It is hard to write a compiler for the language. It is very difficult to optimize.
And, the bits that NEED optimization can be (almost) as easily expressed in C.
The "difficult" run-time systems for the other languages are already proven on systems ranging in performance over several orders of magnitude, and are (normally) expressed in C.
Sure - pick a reasonable Scheme implementation. Something like Gambit www.iro.umontreal.ca/~gambit/
Full number tower. Reasonable compiler. Sane syntax and semantics. Templates for performance? Sure, just partially specialize functions. Since functions are first-class, you CAN operate on them (just like templates, but without losing your mind). Macros that work, and, if you REALLY like infix notation, Gambit support "six" syntax -- a C-like syntax for Scheme.
Compile your code when you are done (both an interpreter and a compiler). Need MORE optimization? Drop in C bits; right in-line with the Scheme code. Or, for "better-than-C" compilation, move to Stalin. en.wikipedia.org/wiki/Stalin_(Scheme_implementation) Possibly the most aggressive optimizing compiler in (common) use.
Maybe -- but do you know something? *I* am the supplier, and NOT the customer. As to the customer -- they get the benefit of dealing with professionals.
You are ABSOLUTELY right. So, what are you going to do about it?
Down to "brass tacks". Let's take a cable company. Say Rogers.
- 60ish analog channels. Work fine with MythTV - Hundreds of SD (standard def) digital channels -- ALL ENCRYPTED. Even the ones that ALSO appear in analog. - Some HD -- but see above point.
Rogers wants to push digital, but with THEIR converter. In fact, its the Rogers converter or the highway (as it were). To use this with MythTV, we need a converter per recording channel.
What do we do? Just say "fuck it all". It is EASIER for me (as a customized MythTV vendor), to supply a simply GUI front-end to EZTV with torrent downloading than to wire up the boxes with the doohickeys needed. And it doesn't look like a mess, either.
Now THAT is truly pathetic -- demand that the customer buy the package, and then ignore it, because it doesn't work, and download the TV from the Rogers cable modem instead.
Now, we have two problems. The customer is (probably) in the clear (if this whole dumb thing were ever aired in court), even though they are (technically) wrong. The big losers are the premium channels. Since the customer is downloading, who is checking for the actual subscription? Rogers doesn't care; they have made money. I would imagine the most aggrieved party (after the cutomer, of course) is HBO, Showtime, etc.
I expect further tightening, and a cable content arms race. After which, the cable company will simply give up. Because... greed gets in the way yet again. After all, the content providers want to make more money, so they distribute boxed sets of DVD/Blu-ray. At which point the content can be (easily) ripped and distributed (and will be, thanks to the aforementioned pissed-off customers).
Win? In order to win, the content must be made available, for a fee, and must be usable. USABLE! NOT FRICKIN' LOCKED IN! If I record, say, an episode of Weeds, and I want to burn it to a standard DVD, let me! I may even (gasp) give that to someone else! But, that's FREE ADVERTISING.
All I want to do is to be able to build out a MythTV box, with some customization, attach it to a cable feed and let MY CUSTOMER be happy.
Since you play games, you are going to insist that users that don't play games pay for an OS for playing games.
Isn't that a bit unfair? Considering that the option to play games is a fifty dollar premium. I assume that you do recommend OpenOffice.org to those who don't need MS Office?
"I think it's great, but would I be comfortable installing it on a friends' or a coworkers computer? heck no! I don't have the years of experience supporting it that I do with windows based systems, so when they ran into some strange driver error or something, I wouldn't really be able to help."
You recommend what you are familiar with... and you don't know what to expect with those "other" operating environments. Fair; but you do realize that then commenting in a discussion about Linux futures is, to put it mildly, obscene.
I wish to point out that I do not comment on Vista, rarely on XP. I would not presume to comment on Windows futures[*].
Your milage, may of course, vary.
---- [*] I may point out good or bad points on the design of the Windows system (In my opinion as a software designer -- Please note that I have award winning Windows products "under my belt", but I am not a day to day Windows user). I also comment on Microsoft business practices.
"there just aren't enough people interested, for example, to allow linux boxes to be sold at places like Circuit City, and I don't think that will change in 4 years."
Linux boxes ARE being sold at places like Circuit City, and people like them. Asus eeepc and aspire, hp small notepad, etc.
As to the rest? Not equilibrium yet. Linux is growing in datacenters; support for large SMP will improve (especially in management; I'd look for the most growth in virtualization). The "GUI" will improve also. There should be growth with 3D drivers (especially AMD(ATI) chipsets). Intel Larrabee should inspire growth in super-computing.
OpenOffice.org/Firefox/other standard applications are coming along nicely. But, with improved 3D will come standard 3D desktop *and* application support (currently, only available with nVidia's hardware and drivers). This should also be possible with ATI and Intel graphic stacks. In turn, this should inspire extra visual support in applications (think real-time graphics rendered from a spreadsheet). Also, I would expect growth in media transcoding.
What should remain stable is the CLI interface, and base software (VIM should still be VI, with enhancements, GCC should improve, but not be radically different, LaTeX will still be kicking, etc.)
Looks like the neurons currently don't have feedback. Adding feedback would be neat. Of course, hitting a wall is negative, finding "food" or avoiding a wall would be negative. I don't know the actual mechanism for feedback/training that the brain uses, but try to trigger it.
So, the current project exploits reflex behavior -- expand it to learned behavior.
So, you need at least two C compilers, with at least one (or both) source available.
Example: build GCC with SUN CC, then GCC to build itself -- presto, "hidden blob patches" are gone. Of course, you are making the assumption that (1) GCC source is "clean", and SUN CC doesn't know to put back trapdoor when it sees GCC source.
Of course you can build your own C compiler - base on something like TCC. But you may be paranoid, and assume that the MACHINE detects sequences (standard prologues). Getting rid of those probably means you are forced to LLVM and a JIT. Or, compile the compiler by hand the first time.
Yes, Linux (as a specific example) uses drivers directly in kernel mode. HOWEVER, those drivers are PART of the OS, distributed and supported WITH the OS, and are Open Source, along with the rest of the kernel. Redhat supports the whole thing.
If drivers are to be supplied "in kernel" this is REQUIRED for reliability. Take Solaris as an example. Source is supplied, along with a DDI layer.
If drivers are supported ONLY via a "DDK" (driver development kit), there must be an isolation between that part of the kernel that CANNOT be understood by the driver developer, and the driver. This was the primary issue with "unreliable" display drivers in the Windows 3.x days -- functionality MUST be implemented, but the reference was not documented, or incorrect.
Indeed, a lot of vendors took extreme steps to deal with this issue -- permanent staff at Microsoft, or (illegally) reverse engineering the support code (GDI).
Unfortunately, the promoted Windows driver development path is "Believe in the DDK, and go" without reference source. Of course, this IS prone to failure -- finally recognized in Vista. (but obvious to vendors since Windows 3.x).
The solution here? Go to a micro-kernel OS. Or, plant parts of device drivers into standard protected mode (user space). Both of which cause performance issues. Or keep part of your software team in Redmond.
Also, given that the interface and driving layer (what I would call a "driver") is under Microsoft's control, the test suites must come from Microsoft as well. If a "crash path" is then NOT exercised, that is ALSO Microsoft's problem. There should be no way for a higher level application to utilize anything OTHER than a tested path to the driver. If it can, the testing is useless, and "Microsoft Certification" is useless.
An analogy at the application layer - SUN has the "application guarantee". That consisted of a series of tools that collected API usage (and could be run by the customer). If an application passed, and then a later upgrade of Solaris BREAKS the application, it is SUN's problem. (SUN fixes the OS or Application).
Hewitt and Smith generalized Alan Kay's work (around 1972), and generalized message passing. Kay suggests procedural embedding could allow the building of functional data structures. Scheme (Sussman and Steele) oiginally implements Hewitt's actors, but observed that actors and functions were the same, dropping actor and keeping lambda.
Sort of this progression:
Lisp->Smalltalk->Actor->Scheme(->Lisp)
In other words, either could be used. The last part is still a work in progress. (Haskell/Caml not included in this picture yet -- this illustrates things late '80s, early '90s - twenty years ago).
Haskell is nice (very nice), although I prefer loose typing, and generally use Scheme.
P5000 (Swift) had 2 Z80s. One for regular use, the second one because the Z80 was less expensive than a full featured disc controller. Ran its own little "micro-program". The Swift could do bank-switching.
P2000 used 8" floppy, P5000 used 5 1/4".
I did OS/DOS and "indirect cli" for the Swift (software was done by 3 people in well under a year). Also, I wrote CP/M 80 BIOS (CP/M 2.2 port) for Swift (after writing a proposal for this).
The software was written in assembler (8080) with Z80 and structure macros. Every byte of memory was accounted for, on a 256x256 wall-chart. There was only (for many months), a single development board. It was distinguished by the fact the the sonalert on it was defective, and would only work when moistened by some spittle.
The software was "modular" in the sense that various load images were stored into document pages. After inserting a "magic" value, the software would appear. A debugger (low level) that I brewed up could be inserted by copying the debug document page into the program image document.
As well, overlays were implemented that allowed arbitrary "patch" and "unpatch" lists. This feature was used to create a "mondo program" - Word Processing, List Processing and Math in a single load image. Marketing suppressed that one right quick!
A notable feature of the P2000 and P5000 was the video controller. Each line could be in a separate part of memory. The P5000 used NMI and software refresh to tell the video controller where to begin the next display line. The P2000 did this in hardware (using a line list). This feature allowing fast scrolling (a bane for a lot of memory mapped display controllers in that era).
The differences between the P2000 and P5000 were motivated by cost reduction (software display line list, software FDC, less glue logic). The P5000 needed only a single logic board -- the P2000 uses a series of boards plugged into a bus.
The P2000 OS was extended into a multi-user system (allowing two displays/users on a single hardware platform). At around the same time, a "cluster" was developed that used a central system.
There was a smaller system based on micro-cassette for storage, but I never worked on this system directly. It had a single (or was it dual?) line display. During development of the Swift (which was a "skunk" project, initiated without much Phillips oversight), a Z8000 project was also being worked on. Lots of theoretical stuff -- b-tree directory and file structures, a new structured programing language, software written at a high level -- it failed because the software needed more than the hardware could deliver (a lot was cross developed on a VAX 780). The P5000 was completed inside of a year. And, it worked.
One of the "high points" in my career - well under budget, and far over expectation. Of course, I was only 20 at the time (JV, the other main contributor was 19, and P the leader was 25, although his role was mostly organizational). One of the truly great teams I have worked with.
- 64KB of memory (yes, not megabytes, kilobytes) - possible bank switching (P5000) for 64KB additional memory - fully pre-emptive OS - didn't use "p/v semaphores", used event bits of synchronization - full interrupt support, able to handle floppy, keyboard, printer i/o and processing concurrently - could edit, print, and copy files at the same time. - two level directories on floppy (document/page structure) - automatic read-after-write checks and re-allocaton of bad blocks (floppy media expensive)
Note that some of these features did NOT appear in common PC systems until 1995 (full preemption). Memory allocation used fixed length blocks -- we couldn't tolerate fragmentation.
It isn't Linux that I am concerned with. It's the entire datacenter.
I work with Solaris. We sell expertise. Used to be, our network was fine - no issues. Then, we had a merger. All of a sudden, the IT dept has to support Windows. What happens?
AD is deployed. This makes Windows happy happy. Not so happy on the Unix front. MS DHCP isn't quite right -- insists on resolv.conf entries that won't work. I can type machine.whole.damn.domain, works. Of course, if I could *use* AD, I would be only typing "machine". As well, printer definitions, etc. are all now Windows centric. Really nasty to access from anything else.
Windows came in, plopped its 800 lb body over EVERYTHING. And it just doesn't like to inter-operate. Says Windows, "I don't have to cooperate! No AD for you".
You know what? It doesn't. Sucks. Everything else inter-operates, and has to get along with new kid, who does things JUST ENOUGH DIFFERENTLY to force lock-in of users who just expect better. Yeah, we edit resolv.conf, and adjust it. Yeah, we have an extra server to buffer away the new printing pains. Yeah, we can export AD entries, and import into NIS. Yeah, we can run parallel file sharing (NFS and SMB). But its annoying to users. May as well just lock-in Windows and be done with it. And, the administration is different enough to create a divide as well.
And, you know what? I don't actually/blame/ Microsoft. After all, they/could/ pull this off. Admirable really. The creation of an entire software ecosystem that really doesn't have much to do with anything else. Jarring when an "external" technology is brought in (tumpet tcp/ip stack? Early MS inter-networking?). Eventually, folded and blended into the juggernaut that is Windows.
But I am still pissed. I understand, but I am not bothering to "learn" the Windows ecosystem. Others can do that, and leave me to my legacy stuff. Thank God I will probably retire soon (yeah, I am the crusty Mainframe & Unix guy here).
Sure, phase out the old, Sign me up; AD rulez! I wouldn't/bother/ to link up Linux (et. al.) to it. If needed, pull AD data, and import into NIS/NIS+ legacy, and get on with the work of replacing Unix with Windows.
"...it is not just an authentication system. It ensures policies (drive mappings, configurations, proxy settings, MS office behaviour and defaults, security standards, etc), deploys software and printers to users and computers"
Of what use is this in anything other than a Microsoft Environment?
How does AD "deploy software and printers" to anything that isn't a Microsoft Environment? And why would you even want it to?
So, from a network viewpoint, AD is just an authentication system. The rest is worthless in a heterogeneous environment.
Slashdot Mirror
$DEITY on a stick!
What compiler was used? (that would be GNU C, C++)
What linker... I'll wait... (that would be GNU ld)
In general, GNU bintools.
What editor? was it emacs? (it could have been vi, or vim). But, if you use emacs...
What shell? Bash. GNU again.
As to the "ogg" -- mpeg-2 patents: http://www.mpegla.com/m2/m2-agreement.cfm
mpeg-1 uses mp3 audio, which is patented. Heck, even fedora doesn't play it!
AVI? Its a fucking minefield (I REALLY don't have the time to post the patents involved -- fortunately a lot of the companies involved are dead, or don't care -- allowing us to play these formats with x86 shims).
GNU means ONLY open, which means... ogg. Get over it. The FSF would make no other choice.
The GPU is (generally) a vector processor with VERY limited branching capability, and VERY limited data sourcing. But, these things can be "fixed".
Yes, Intel is working on an "x86 GPU".
"Larrabee can be considered a hybrid between a multi-core CPU and a GPU, and has similarities to both. Its coherent cache hierarchy and x86 architecture compatibility are CPU-like, while its wide SIMD vector units and texture sampling hardware are GPU-like." (from http://en.wikipedia.org/wiki/Larrabee_(GPU) )
As to Cg being "open sourced"? Nope, it is available, but the ISA of the nVidia chip is still closed. If I *could* I would work a vector/flow backend compiler for (a subset of) scheme to support it. But I can't. I will be able to with LARRABEE. I would probably base a compiler on Marc Feeleys picoscheme work. But... well, I can't.
How is a "GPU" different from a "CPU"? If you take them to be the SAME, you end up with Intels LARRABEE. If you take them as somehow DIFFERENT, you end up with nVidias proclamation.
If they are considered the SAME, but with different performance tunings, other applications begin to open up.
As an example: it is currently true that the "GPU" is given an exorbitant amount of resources to do one thing -- create visuals for games.
And that's it. It contains a significant amount of the system memory, and processing logic, and "locks it away". Which is very good if you are selling the graphics cards, but not ideal (at all) for the customer.
If the graphics card can be placed closer and more generally, the customer would win. EXCEPT -- for one problem (and, boy is it a doozy).
The nVidia is programmed with a specific higher-order assembly language, We rely solely on the hardware vendor for tools. I think that this is UNIQUE in the (mass-market) processor world. And this is why Intel, with an x86 compatible GPU is such a threat. Can anyone else produce an OpenGL shader compiler for the nVidia? Or, better yet, extend it to do NON-shader tasks. How about for the AMD? Yes, you CAN for Intel, and will, by design be able to (I would expect, even ENCOURAGED) for LARRABEE.
The idea is to extend the "NUMA" concept for memory to processors. Intel is doing it because others are already doing it - SUN with Niagra and Niagra 2 are providing an absolutely amazing proof of concept. (except with multi-core and FPU units).
Why would you BOTHER with a specific purpose GPU, if you could have a (possibly less performant) workable solution with more cores, AND be able to use them for other tasks?
Of course this is not particularly relevant to TODAYs applications. They are matched to current hardware. Now, I will bring up the L word - Linux. Linux is suited to a much wider degree of scaling (practically) and runs on ARM up to Z/Series. It also supports NON-x86 ISAs. Which would mean that a non-x86 version of this idea is probably supportable. But, it wouldn't run CURRENT software, and, I believe, would be a complete non-starter.
But, take this with a grain of salt -- I am obviously not a great predictor (otherwise I would already be retired).
MPEG is NOT designed for streaming?!?!?
So, I guess "TS" doesn't standard for "Transport Stream", and there aren't any PTS (Presentation Time Stamps)... Oh crap, I guess MPEG doesn't come from satellites after all :(
And, I guess the small TS stream packet sizes and inclusion of I-Frames doesn't allow you to just jump on a stream at any time! More sadness :(
Anyway, you must know. I stand corrected.
Leapin' Lizards!
Who in their right mind CARES? You pick a well-supported standard format: Um... let's see, MPEG, XVID, VIDX, AVI container, MPEG container, MP3 sound, AC3 sound, whatever... and put the video up.
What? They didn't do that? They picked a new format for some reason; one that requires a platform refresh, and unholy amount of effort. Didn't even use (gasp) FLASH video?
Why on Earth would anyone do that?
The only 'splaining here is why a Political Party that will (most likely) be running the most powerful country on the planet is actually allowed to get a rim-job from a private company. Not that *I* could care -- but that is pushing the classic boundary commonly known a facist. Along with the rim-jobs the US gov' received from terrestrial radio, And etc.
Oh -- I here you saying "But the Dems didn't get a rim-job from Microsoft! They did it by themselves!" In which case, I think it's worse -- they SHOULD have held out for lots of plums before forcing that move.
Me? I don't care; enjoy yourselves!
Vote Democrat! Vote Microsoft! Vote Republican! Vote Microsoft! Just be sure to Vote!
How does ssh do it? Easy. The FIRST time it says that you have never used this system, and would you like to accept it. If the key EVER changes, you are "thrown out" by default. Bad error!
Works for ssh... Now I COULD tell my users to tunnel http through ssh instead of using https: but (and this is funny), SSL with FF3 works the same as ssh (key info change == bad error). So, why the (irrational) initial dialogs?
As to the http tunnel -- it would work (for some measure of work) BUT if ssh is not available, the temptation would be to simply use http. Which is bad (VERY BAD). So, I would never enable it. Instead, I vector access to the https pages via an http page, that contains details as to what to expect. Problem "solved".
Anyway, I was commenting on the GPs idea that somehow self-signed certificates result in a communication that is "less secure". Which is just plain wrong.
"it is security at a much higher level than using a self-signed crutch"
Explain please. Exactly how is it more secure? Clue: the signing has NOTHING to do with the security.
I personally don't have issues with security and my (personal) web sites. I do have issues with running a plaintext connection. Indeed I know who I am, and I would like to have private conversations with myself (as it were). An example is my wiki -- closed access (well, open to 5 people on the planet). Uses SSL, to avoid snooping of user/password and even the CONTENTS of the messages. I don't trust CAs, and, for this application don't need to trust a CA. Actually, my SECURITY for this wiki is better than a "signed CA" -- simply by remaining self-signed.
Sorry for replying to myself.
I guess that C++ could (in a demented way) be viewed as a functional language. I imagine that template expansion could be viewed as functional programming (assuming your compiler doesn't blow up) to implement this at compile time.
Please expand: C++ is a functional language? Can you actually code without (imperative) assignment?
C++ is an OOP language? Can objects be completely isolated?
And WHY would "smart pointers" be needed in a functional language anyway? Or even in an OOP language. Isn't the point of EITHER of these paradigms to eliminate that need?
For 32KB systems, I would recommend either absolute assembler, or program conversion - higher order to lower order (subset Scheme to assembler, and possibly TinyScheme). Even C is excessive, but possible. C++? Unless you have absolute control on template production, I would doubt it.
Simply because using the STL and making a SINGLE type change can result in inclusion of thousands of bytes of code (as the templates instantiate). Example: modify a short vector to a long int vector on the platform. The machine code will now have to include math libraries, and all the overhead of instantiating. Easily 30KB, which then blows out your 16KB deliverable.
And, it isn't possible to put source level checks in place to prevent this.
Yes, C is a "high level" assembler (low level language), but is better suited for this type of development. Now, the code being targeted at this platform typically DOES NOT HAVE TO BE PORTABLE. Normally, every byte has to be accounted for anyway, making absolute assembler very practical. None of the higher order C++ constructs are useful, because abstraction is simply not a consideration on these platforms. C is useful, because it is easier than learning yet another assembler. Scheme can be useful, because it is easy to generate a subset compiler yourself to the target platform. (more people can do the Scheme, than can successfully generate a C compiler).
Back to "portability": In this space the following code would make a lot of sense, and is considered "portable"
#define BASE 0x7000 ... ...
#define STATUS (BASE+1)
#define READY 0x0001
#define NOTHING
char *status = (char *)STATUS;
while ((*status & READY) == 0)
NOTHING;
(but there is no timeout implemented, this was just an example).
My CV in this area: biometers, micro-controllers (SCSI, other), heads-up displays, etc. And with ALL systems in the 64KB and less capacity, I have NEVER been asked to do C++. Nor have I ever recommended it. I would be curious if there have been success stories in this particular space.
Of course the customer isn't my property. I am simply stating that putting in place service requirements can be good for the customer (they know what they are getting), and good for the providers (it stabilizes the market).
It already happens in other industries (taxi, medical, etc.). FYI - why is accreditation required to deliver the results of a medical instrument, and yet NOT required when programming the same instrument? Even when we know that some medical instruments have killed patients.
A bit, um..., twisted.
Any platform that has a C compiler can run Gambit-C (Python is in the same "class"). Of course, some platforms may be... to anemic to support Scheme. But, the proof in the pudding is TinyScheme, and LispMe (TinyScheme is a very small, VERY portable implementation of a Scheme interpreter, and LispMe is a Scheme implementation on a 68000 Palm platform).
Python is ALSO available on the 68000 (Palm) -- Pippy is the name of the implementation.
So, for some data points - both Scheme and Python have at least one (for reference) implementation on the 68000. I am not sure if I can pull this back to 16 bit addressable platforms (z80 et al) or 20 bit platforms (8086). But this doesn't really matter these days.
Indeed, even SNOBOL4 from the 60's is portable -- now that we have a reference C implementation (SNOBOL-C). This implementation implements the macro base in C, making it portable to machines with a sufficient address space. All of these systems (Scheme, Python, Snobol4) run on 32 bit x86 little-endian Linux, and 64 bit Sparc big-endian Solaris. Portable enough?
Now, C++ is "tricky" to get right. The compiler needs to be almost insanely well-done in order to optimize. It is VERY hard to be introspective on code (C++ = practically impossible, without actually implementing the compiler, Python = merely hard, SNOBOL4 = easy, but a bit weird, Scheme = easy, bordering on trivial).
It is almost impossible to look at C++ code in isolation, and determine what it does, let alone if it is correct. It is hard to write a compiler for the language. It is very difficult to optimize.
And, the bits that NEED optimization can be (almost) as easily expressed in C.
The "difficult" run-time systems for the other languages are already proven on systems ranging in performance over several orders of magnitude, and are (normally) expressed in C.
Again, why C++?
Sure - pick a reasonable Scheme implementation. Something like Gambit www.iro.umontreal.ca/~gambit/
Full number tower. Reasonable compiler. Sane syntax and semantics. Templates for performance? Sure, just partially specialize functions. Since functions are first-class, you CAN operate on them (just like templates, but without losing your mind). Macros that work, and, if you REALLY like infix notation, Gambit support "six" syntax -- a C-like syntax for Scheme.
Compile your code when you are done (both an interpreter and a compiler). Need MORE optimization? Drop in C bits; right in-line with the Scheme code. Or, for "better-than-C" compilation, move to Stalin. en.wikipedia.org/wiki/Stalin_(Scheme_implementation) Possibly the most aggressive optimizing compiler in (common) use.
Back to you -- why C++?
"to the detriment of the customer."
Maybe -- but do you know something? *I* am the supplier, and NOT the customer. As to the customer -- they get the benefit of dealing with professionals.
I would love to organize.
You know what?
You are ABSOLUTELY right. So, what are you going to do about it?
Down to "brass tacks". Let's take a cable company. Say Rogers.
- 60ish analog channels. Work fine with MythTV
- Hundreds of SD (standard def) digital channels -- ALL ENCRYPTED. Even the ones that ALSO appear in analog.
- Some HD -- but see above point.
Rogers wants to push digital, but with THEIR converter. In fact, its the Rogers converter or the highway (as it were). To use this with MythTV, we need a converter per recording channel.
What do we do? Just say "fuck it all". It is EASIER for me (as a customized MythTV vendor), to supply a simply GUI front-end to EZTV with torrent downloading than to wire up the boxes with the doohickeys needed. And it doesn't look like a mess, either.
Now THAT is truly pathetic -- demand that the customer buy the package, and then ignore it, because it doesn't work, and download the TV from the Rogers cable modem instead.
Now, we have two problems. The customer is (probably) in the clear (if this whole dumb thing were ever aired in court), even though they are (technically) wrong. The big losers are the premium channels. Since the customer is downloading, who is checking for the actual subscription? Rogers doesn't care; they have made money. I would imagine the most aggrieved party (after the cutomer, of course) is HBO, Showtime, etc.
I expect further tightening, and a cable content arms race. After which, the cable company will simply give up. Because... greed gets in the way yet again. After all, the content providers want to make more money, so they distribute boxed sets of DVD/Blu-ray. At which point the content can be (easily) ripped and distributed (and will be, thanks to the aforementioned pissed-off customers).
Win? In order to win, the content must be made available, for a fee, and must be usable. USABLE! NOT FRICKIN' LOCKED IN! If I record, say, an episode of Weeds, and I want to burn it to a standard DVD, let me! I may even (gasp) give that to someone else! But, that's FREE ADVERTISING.
All I want to do is to be able to build out a MythTV box, with some customization, attach it to a cable feed and let MY CUSTOMER be happy.
Since you play games, you are going to insist that users that don't play games pay for an OS for playing games.
Isn't that a bit unfair? Considering that the option to play games is a fifty dollar premium. I assume that you do recommend OpenOffice.org to those who don't need MS Office?
"I think it's great, but would I be comfortable installing it on a friends' or a coworkers computer? heck no! I don't have the years of experience supporting it that I do with windows based systems, so when they ran into some strange driver error or something, I wouldn't really be able to help."
You recommend what you are familiar with... and you don't know what to expect with those "other" operating environments. Fair; but you do realize that then commenting in a discussion about Linux futures is, to put it mildly, obscene.
I wish to point out that I do not comment on Vista, rarely on XP. I would not presume to comment on Windows futures[*].
Your milage, may of course, vary.
----
[*] I may point out good or bad points on the design of the Windows system (In my opinion as a software designer -- Please note that I have award winning Windows products "under my belt", but I am not a day to day Windows user). I also comment on Microsoft business practices.
"there just aren't enough people interested, for example, to allow linux boxes to be sold at places like Circuit City, and I don't think that will change in 4 years."
Linux boxes ARE being sold at places like Circuit City, and people like them. Asus eeepc and aspire, hp small notepad, etc.
As to the rest? Not equilibrium yet. Linux is growing in datacenters; support for large SMP will improve (especially in management; I'd look for the most growth in virtualization). The "GUI" will improve also. There should be growth with 3D drivers (especially AMD(ATI) chipsets). Intel Larrabee should inspire growth in super-computing.
OpenOffice.org/Firefox/other standard applications are coming along nicely. But, with improved 3D will come standard 3D desktop *and* application support (currently, only available with nVidia's hardware and drivers). This should also be possible with ATI and Intel graphic stacks. In turn, this should inspire extra visual support in applications (think real-time graphics rendered from a spreadsheet). Also, I would expect growth in media transcoding.
What should remain stable is the CLI interface, and base software (VIM should still be VI, with enhancements, GCC should improve, but not be radically different, LaTeX will still be kicking, etc.)
Looks like the neurons currently don't have feedback. Adding feedback would be neat. Of course, hitting a wall is negative, finding "food" or avoiding a wall would be negative. I don't know the actual mechanism for feedback/training that the brain uses, but try to trigger it.
So, the current project exploits reflex behavior -- expand it to learned behavior.
See if the little buggers can train themselves...
So, you need at least two C compilers, with at least one (or both) source available.
Example: build GCC with SUN CC, then GCC to build itself -- presto, "hidden blob patches" are gone. Of course, you are making the assumption that (1) GCC source is "clean", and SUN CC doesn't know to put back trapdoor when it sees GCC source.
Of course you can build your own C compiler - base on something like TCC. But you may be paranoid, and assume that the MACHINE detects sequences (standard prologues). Getting rid of those probably means you are forced to LLVM and a JIT. Or, compile the compiler by hand the first time.
Wrong. WRONG.
Yes, Linux (as a specific example) uses drivers directly in kernel mode. HOWEVER, those drivers are PART of the OS, distributed and supported WITH the OS, and are Open Source, along with the rest of the kernel. Redhat supports the whole thing.
If drivers are to be supplied "in kernel" this is REQUIRED for reliability. Take Solaris as an example. Source is supplied, along with a DDI layer.
If drivers are supported ONLY via a "DDK" (driver development kit), there must be an isolation between that part of the kernel that CANNOT be understood by the driver developer, and the driver. This was the primary issue with "unreliable" display drivers in the Windows 3.x days -- functionality MUST be implemented, but the reference was not documented, or incorrect.
Indeed, a lot of vendors took extreme steps to deal with this issue -- permanent staff at Microsoft, or (illegally) reverse engineering the support code (GDI).
Unfortunately, the promoted Windows driver development path is "Believe in the DDK, and go" without reference source. Of course, this IS prone to failure -- finally recognized in Vista. (but obvious to vendors since Windows 3.x).
The solution here? Go to a micro-kernel OS. Or, plant parts of device drivers into standard protected mode (user space). Both of which cause performance issues. Or keep part of your software team in Redmond.
Also, given that the interface and driving layer (what I would call a "driver") is under Microsoft's control, the test suites must come from Microsoft as well. If a "crash path" is then NOT exercised, that is ALSO Microsoft's problem. There should be no way for a higher level application to utilize anything OTHER than a tested path to the driver. If it can, the testing is useless, and "Microsoft Certification" is useless.
An analogy at the application layer - SUN has the "application guarantee". That consisted of a series of tools that collected API usage (and could be run by the customer). If an application passed, and then a later upgrade of Solaris BREAKS the application, it is SUN's problem. (SUN fixes the OS or Application).
Horrible Simplification Follows
Hewitt and Smith generalized Alan Kay's work (around 1972), and generalized message passing. Kay suggests procedural embedding could allow the building of functional data structures. Scheme (Sussman and Steele) oiginally implements Hewitt's actors, but observed that actors and functions were the same, dropping actor and keeping lambda.
Sort of this progression:
Lisp->Smalltalk->Actor->Scheme(->Lisp)
In other words, either could be used. The last part is still a work in progress. (Haskell/Caml not included in this picture yet -- this illustrates things late '80s, early '90s - twenty years ago).
Haskell is nice (very nice), although I prefer loose typing, and generally use Scheme.
Naw... Micom P2000 was 8080 based.
P5000 (Swift) had 2 Z80s. One for regular use, the second one because the Z80 was less expensive than a full featured disc controller. Ran its own little "micro-program". The Swift could do bank-switching.
P2000 used 8" floppy, P5000 used 5 1/4".
I did OS/DOS and "indirect cli" for the Swift (software was done by 3 people in well under a year). Also, I wrote CP/M 80 BIOS (CP/M 2.2 port) for Swift (after writing a proposal for this).
The software was written in assembler (8080) with Z80 and structure macros. Every byte of memory was accounted for, on a 256x256 wall-chart. There was only (for many months), a single development board. It was distinguished by the fact the the sonalert on it was defective, and would only work when moistened by some spittle.
The software was "modular" in the sense that various load images were stored into document pages. After inserting a "magic" value, the software would appear. A debugger (low level) that I brewed up could be inserted by copying the debug document page into the program image document.
As well, overlays were implemented that allowed arbitrary "patch" and "unpatch" lists. This feature was used to create a "mondo program" - Word Processing, List Processing and Math in a single load image. Marketing suppressed that one right quick!
A notable feature of the P2000 and P5000 was the video controller. Each line could be in a separate part of memory. The P5000 used NMI and software refresh to tell the video controller where to begin the next display line. The P2000 did this in hardware (using a line list). This feature allowing fast scrolling (a bane for a lot of memory mapped display controllers in that era).
The differences between the P2000 and P5000 were motivated by cost reduction (software display line list, software FDC, less glue logic). The P5000 needed only a single logic board -- the P2000 uses a series of boards plugged into a bus.
The P2000 OS was extended into a multi-user system (allowing two displays/users on a single hardware platform). At around the same time, a "cluster" was developed that used a central system.
There was a smaller system based on micro-cassette for storage, but I never worked on this system directly. It had a single (or was it dual?) line display. During development of the Swift (which was a "skunk" project, initiated without much Phillips oversight), a Z8000 project was also being worked on. Lots of theoretical stuff -- b-tree directory and file structures, a new structured programing language, software written at a high level -- it failed because the software needed more than the hardware could deliver (a lot was cross developed on a VAX 780). The P5000 was completed inside of a year. And, it worked.
One of the "high points" in my career - well under budget, and far over expectation. Of course, I was only 20 at the time (JV, the other main contributor was 19, and P the leader was 25, although his role was mostly organizational). One of the truly great teams I have worked with.
"Barely had an operating system" -- my ass.
Take the Philips P2000/P5000 series.
Yes, I wrote the OS and DOS. Some features:
- 64KB of memory (yes, not megabytes, kilobytes)
- possible bank switching (P5000) for 64KB additional memory
- fully pre-emptive OS
- didn't use "p/v semaphores", used event bits of synchronization
- full interrupt support, able to handle floppy, keyboard, printer i/o and processing concurrently
- could edit, print, and copy files at the same time.
- two level directories on floppy (document/page structure)
- automatic read-after-write checks and re-allocaton of bad blocks (floppy media expensive)
Note that some of these features did NOT appear in common PC systems until 1995 (full preemption). Memory allocation used fixed length blocks -- we couldn't tolerate fragmentation.
It isn't Linux that I am concerned with. It's the entire datacenter.
I work with Solaris. We sell expertise. Used to be, our network was fine - no issues. Then, we had a merger. All of a sudden, the IT dept has to support Windows. What happens?
AD is deployed. This makes Windows happy happy. Not so happy on the Unix front. MS DHCP isn't quite right -- insists on resolv.conf entries that won't work. I can type machine.whole.damn.domain, works. Of course, if I could *use* AD, I would be only typing "machine". As well, printer definitions, etc. are all now Windows centric. Really nasty to access from anything else.
Windows came in, plopped its 800 lb body over EVERYTHING. And it just doesn't like to inter-operate. Says Windows, "I don't have to cooperate! No AD for you".
You know what? It doesn't. Sucks. Everything else inter-operates, and has to get along with new kid, who does things JUST ENOUGH DIFFERENTLY to force lock-in of users who just expect better. Yeah, we edit resolv.conf, and adjust it. Yeah, we have an extra server to buffer away the new printing pains. Yeah, we can export AD entries, and import into NIS. Yeah, we can run parallel file sharing (NFS and SMB). But its annoying to users. May as well just lock-in Windows and be done with it. And, the administration is different enough to create a divide as well.
And, you know what? I don't actually /blame/ Microsoft. After all, they /could/ pull this off. Admirable really. The creation of an entire software ecosystem that really doesn't have much to do with anything else. Jarring when an "external" technology is brought in (tumpet tcp/ip stack? Early MS inter-networking?). Eventually, folded and blended into the juggernaut that is Windows.
But I am still pissed. I understand, but I am not bothering to "learn" the Windows ecosystem. Others can do that, and leave me to my legacy stuff. Thank God I will probably retire soon (yeah, I am the crusty Mainframe & Unix guy here).
Sure, phase out the old, Sign me up; AD rulez! I wouldn't /bother/ to link up Linux (et. al.) to it. If needed, pull AD data, and import into NIS/NIS+ legacy, and get on with the work of replacing Unix with Windows.
K?
"...it is not just an authentication system. It ensures policies (drive mappings, configurations, proxy settings, MS office behaviour and defaults, security standards, etc), deploys software and printers to users and computers"
Of what use is this in anything other than a Microsoft Environment?
How does AD "deploy software and printers" to anything that isn't a Microsoft Environment? And why would you even want it to?
So, from a network viewpoint, AD is just an authentication system. The rest is worthless in a heterogeneous environment.
[Proxy settings are useful].