Re:Several Issues - Tools ARE very important!
on
Clockless Computing?
·
· Score: 2
Logic synthesis tools are very important to modern day IC design and optimization.
That is why Theseus Logic, Inc. (mentioned about 2/3rds down in the NYTimes article) has a Strategic Alliance with Synopsys. Our patented NCL (Null Convention Logic) technology, unlike many other asynchronous technologies, is designed for maximum interoperability with existing tools, maximum design reuse and near-complete elimination of common CBL (clocked boolean logic) timing closure issues.
Disclaimer: I am an employee of Theseus Logic, Inc., who is NOT speaking on behalf of Theseus Logic in this post, nor his its content been approved by any Theseus Logic official.
The exception is where the course is mandated by the company to fill an immediate need.
You'd be surprised how many companies don't have that "exception." The ones that "require" you to be trained for your job, and expect you to reimburse them if you leave is utter bull. If my continued employment requires training, I expect the company to have no strings attached.
But if I get training that is not mandatory or required, they company should be able to "protect" their investment within reason. That is all your company is trying to do. If anything, company's should "pro-rate" the reimbursement, instead of making it a plateau date.
Blame the media for creating this "web of distrust" regarding the Internet. Don't get me wrong, your default attitude should be distrust when it comes to system security itself. But when you get someone on the line, in voice, or in a sincere correspondence, your first instinct should be to "thank" them. The great majority of people are quite ethical. Otherwise Melissa (and most of the original worms) would have wiped out most Windows systems on the first shot instead of just being a benign worm.
With the Quake series, idSoftware found the Intel 32-bit integer loads from memory to 32-bit general-purpose register to be piss-poor slow. With a little tinkering, they found that on the Pentium, loading two 32-bit integers into a 64-bit floating point register, and then moving those integers from register to register was much faster. Why? With the Pentium, Intel really worked hard on FPU to bring it up to more common RISC-implementation performance (the 80x87 ISA has always been a poor FPU implementation, remember Weitek?;-), and created a well pipelined FPU in the Pentium (over other x86 processors at the time). Pipelining means that more than one instruction can be worked on by a unit simultaneously -- if similiar instructions follow one another.
Most fast, interpolated 3-D geometry usually involves sets of regularly, well-timed, memory loads of four to sixteen (4-16), 32-bit reads for each operand into registers (usually 1x4 or 4x4 matrix of 32-bit, interpolated integer coordinates in 3-D space). Again, loading through the traditional integer opcode was piss-poor slow -- and id, again, found that the new Pentium chip offered a "workaround" via its new, pipelined FPU.
Because this was "unorthodoxed", most compilers simply did not implement this. If you tried to read integers from memory, it would use the integer load opcode. So idSoftware had to write their own replacement memory read/write routines and functions. Undoubtably, this was done easiest in assembler.
BTW, this "Pentium optimization" was why the first generation of AMD and Cyrix processors lagged in Quake performance. Not because their FPU "sucked", but the idSoftware optimizations relied on the performance of a pipelined FPU -- not something AMD or Cyrix had in their first generation of Pentium ISA-compatible products. In fact, AMD's K6 (Nx686 core) had an excellent, non-pipelined FPU that was faster at execution -- provided your program was comprised of random integer/ALU, FPU and control opcodes. And if idSoftware would have just left the regular integer load in, the K6's integer memory load was upto 3x faster than the non-MMX Pentium and would have smacked the Pentium silly.
In most modern, general-purpose programs, assembler has rarely been used to "increase performance" over traditional program language code -- with rare exceptions going to heavily used functions that a profiler might pick up. And even then, most assembly is part of a larger program and a fraction of the total code -- usually in-line in the high-level language, or a self-containted object referenced by the other high-level language code. But even then, today's compilers are good optimizers and can even best you on your assembler if you don't know what you are doing.
No, for the past decade, assembler is still in use for raw, system-level details. Just like the Linux kernel, some things need to get done with GAS. Even NT's init loader is like this as well.
Most CS and engineering programs still teach assembler not to be proficient, but to understand the machine code v. man code relationship. It's not a full-up course where you write programs only in assembler -- in fact, I had a class on system-level programming where I wrote an assembler in C and binutils (lexx, awk, etc...). Why? It taught me not only assembler fundamentals, but the concepts of machine code and organization, basic parsing, hash tables, referencing and other concepts -- all in one course, in a very practical manner!
No, people why say "why code in assembler anymore?" are the people who continue to fail to understand why assembler ever existed. Heck, even Cobol and Fortran were available in the 50s! It was rarely a matter of "speed", but the fact that speed and size are "real-world constraints" at the system-level.
Forget that X-Windows source code rip with security issues (also known as "NT Terminal Server";-) and save some dough by just use a SSH client with port forwarding (like TeraTerm + TTSSH and VNC). It works great at my company, letting me support my notebook and other roaming users while they are on the road. TeraTerm+TTSSH is cake to setup, and you can configure it so all a user has to do is click an icon to connect with port forwarding.
First off, If you get anything out of this
post it is this: DO NOT RUN A REDHAT X.0 RELEASE IF YOU DON'T UNDERSTAND LIBRARY VERSIONING
NO SUCH THING AS "GLIBC HELL"
There is _no_such_thing_ as "glibc Hell". UNIX (including Linux)
has versioning on libraries -- right down tot he filename. _Unlike_
Windows, you can have _multiple_library_versions_ installed. Even
Microsoft still has NOT addressed this (and I run into it daily)
simply by versioning filenames of libraries. This is a _farce_ and
the result of people not understanding the OS in front of them.
UNIX v. WINDOWS ON SYSTEM LIBRARIES
So, in a nutshell, you can have your library issues two ways:
UNIX: Versioning on system libraries, which gives you 2 options:
Recompile for new libraries (if you have source)
Install older libraries (especially if you don't have source)
WINDOWS: Only one system library can be installed, which gives you
only 1 option:
Recompile for new libraries (if you have source)
Otherwise, no option if you don't have source -- total SOL! Especially on Win2K which makes some libraries untouchable
(and quite incompatible with a lot of existing software).
Microsoft does this for "stability", but it is a library-
ignorant way of NOT addressing the _real_ issue, lib
versioning.
LIBRARY VERSIONING AND SYMBOLIC LINKS
The main reason Windows cannot have UNIX-like library versioning and
versioning on filenames is because it lacks symbolic links. With
symbolic links, you can have multiple subrevision of a library, with
one subrevision the "default" revision, with that (or another) the
default "main" version. E.g.,:
In the preceding example, there are actually only 4 library
versions: 1.0.7, 1.1.2, 1.1.3 and 3.0.1. We could easily introduce
more versions if programs required them. Most libraries are "parent
revisioned" (I don't know what the "official term" is, but that's
what I'll call it), so the latest "x.y.z"
"version.revision.subrevision" is synlinked as "x.y"
"version.revision" as well as "x" "version". As far as compatility
between versions, anything goes (and is a per-library
consideration), but the "general rule" is as follows:
Most OSS projects, including GLibC, have good versioning schemes
that change subrevisions (the "Z" in x.y.z when updates, bugfixes,
or non-structural changes are made -- meaning 1.1.2 and 1.1.3 are
most likely header/function compatible. So, depending on the
library, most programs are fine when linking against X.Y instead of
x.y.z-- and do so to keep from requiring the user to have numerous
differnet libraries installed. A simple x.y symlink to the latest
x.y.z (latest being the max(Z)) is usually all it takes. Again, a
"parent revision" symlink does the job.
Now different revisions (the "Y" in x.y.z) usually involve some
header/function changes that _may_ be INcompatible. As such vendors
usually do not link against just the major version (the "X" in
x.y.z) for that reason. E.g., some programs work fine on any GLibC
2.y.z system (BTW, GLibC 2 is aka LibC 6), but most are tied to
GLibC 2.0.z (RedHat 5.x), GLibC 2.1.z (RedHat 6.x) or GLibC 2.2.z
(RedHat 7.x). Major version changes (again, the "X" in x.y.z) are
left for radical, completely incompatible changes -- like LibC 4
(RedHat 3.x), LibC 5 (RedHat 4.x) and GLibC 2 (RedHat 5.x+ -- which
caused a bigger stir than 7.0 awhile back;-PPP).
DON'T RUN A REDHAT X.0 RELEASE UNLESS YOU KNOW WHAT YOU ARE DOING!
98% of the "bitching and moaning" about RedHat 7.0 comes from user
naivity on library versioning. Yes, I _do_agree_ that RedHat did
release 7.0 too earlier with unfinished components, but since
patching GLibC and GCC through December, RedHat 7.0 is a _solid_
release. Never, never adopt a RedHat X.0 release unless you are a
seasoned Linux user! Please get the word out on that (although the
RedHat 7.0 README on CD 1 *DOES* stress that point too!!!)
[ Side note: The kernel is another matter though -- but understand
RedHat cannot "time" the release of GLibC, GCC and the kernel since
they are all independent development teams. ]
RedHat gives you _full_warning_ of the all-important GLibC change in
a new release. It's always been RedHat's model -- introduce a new,
and possibly INcompatible GLibC on a X.0 release. All revisions in
a major release have the same GLibC and GCC, and are quite
interchangable. I've said it before and I'll say it again, only
RedHat seems to do this (although I haven't checked out Debian
yet). So I know that going from 6.2 to 7.0 means issues, just like
4.2 to 5.0 did for me almost a half-decade ago. NOTHING NEW!
So, again, if you do NOT know what you are doing, stick with RedHat
X.2 releases (or at least X.1)!!! At X.0 releases, most of the
Linux world has NOT yet adopted the new GLibC versions -- hence the
wealth of binary library incompatibilities. So if you are not
familiar with how to deal with them, do NOT try to deal with a
RedHat X.0 release!
REDHAT MAINTAINS LIBRARY COMPATIBILITY
Today's RedHat 7.0 (GLibC 2.2) release comes with full RedHat 6.x
(GLibC 2.1) compat libs, even a compat devel libs and a compat
compiler/linker. And you can also install compat libs from the
RedHat 6.2 release for 4.x (LibC 5) and 5.x (GLibC 2.0)
compatibility.
[ Side note: I *DO* have a "complaint" with RedHat for not
including LibC5 and GLibC2.0 compatibility libraries with RedHat
7.0. And I've let Alan Cox know about them. They should _at_least_
be available on the Powertools CD. I know LibC4 shouldn't be
included for security reasons, but LibC5 and, especially, GLibC2.0
should be! ]
ANY LIBRARY ISSUES ARE ALMOST ALWAYS THE PACKAGERS FAULT!
Now that we have the user out of the way, as long as a
vendor/packager dynamically links against the specific library
version, the binary will use that version. Too many vendors are
used to just linking against what they have, especially if it is an
older library on their development system. So when a user has a new
version of the library, possible with function name, parameter and
other structrual changes, core dumps will occur.
If a developer is really worried, there is always the option of
statically linking -- i.e. putting the library in the binary itself
(so no external library references/dependencies). Of course, there
could be licensing issues with GPL or other OSS code to/from
commerical and vice-versa. If people think this is limited to
Linux, they are _gravely_mistaken_ as most commercial IDE and
development tools introduce their own issues. Under Windows, where
only one system library can be installed (and that library may be
"fixed" in Win2K), you're in for a world of hurt trying to sort them
out.
END-USER LIBRARY VERSION ADMINISTRATION
As previously discussed, symlinks are often used to "parent
revision" a full "x.y.z" "version.revision.subrevision". Most of
the time, RPMS and tarballs/makes installs do this for you. But
sometimes, you'll have to administer and create them yourself.
Again, doing this is usually easy (it's just a symlink -- "ln -s
") and the first thing to try
when a program cannot find a library (e.g., libmy-2.0) where a
library exists with a more complete version (e.g., libmy-2.0.1).
GnomeOffice Dia is a UML-based diagramming and vector graphics app. You can extend it with XML/UML (and conforms to the full UML spec as defined by its XML DTD) and it supports a plethora of standard graphics formats for inport and export. There are numerous documents on the web that use Dia as an example of learning XML/UML programming to a DTD spec.
I work for a fabless semiconductor design firm and we are almost entirely UNIX-based. We use Innoveda ViewLogic (see products associated with ViewDraw) for our schematic capture. At my previous employer, an aerospace firm, we also used ViewLogic for PCB Layout.
The only kicker is that ViewLogic is expensive for the UNIX version. As such, even we run the Windows version on some. But everything else, our Cadence, Mentor Graphics, Modeltech and Synopsys tools all run on either Solaris or, increasingly, Linux (as more and more vendors offer then).
Yes, there *IS* a lot of "overlap" between the applications of the two. Regardless, my original statements hold true on how and who for the Pentium microprocessor is designed versus how and who for the StrongARM microcontroller is designed.
Microprocessors range from simplistic, single-issue CPUs to the nine-issue, massively buffered K7. Microcontrollers range from basic 8-bit cores to the 32-bit superpipelined StrongARM with external, co-processor options.
Your application will be the best judge of what to use.
You'll find the article here: IEEE-CS Computer Magazine, Vol. 33, No. 8, August 2000, under the section "Standards". Again, the article is Windows 2000: A Threat to Internet Diversity and Open Standards? by David Chadwick of the IETF.
More importantly, the context of this posting is that someone booted Linux on it and that people built PDAs based on this processor, so it's not just being used as an I/O controller for RAIDs.
Yes. But, and I hope you agree with:
There are a crapload of non-consumer, ARM-based systems running Linux today. I know they are getting very popular for military and scientific applications. That is a significant share of even the Linux market -- so were still talking about more than just PDAs, even when talking only running Linux.
PDAs run far fewer, simultaneous processes than a desktop (let alone a server). Even if you figure in the networking stack and a few running apps, it's still far less intensive.
On most modern processors, you actually often get faster performance if you implement using FP because integer arithmetic (for loops and indexes) and FP arithmetic can happen in parallel.
A well informed post, greatly appreciate the insight. So now I ask:
Would it still be as fast on a microcontroller, like the ARM products, with a single pipe? That would prevent multiple, parallel operations, right? So you back to talking about multi-issue microprocessors, when the post was about a single-issue microcontroller.
From my understanding, much of the use of the FPU on Intel microprocessors stem from their poor ALU implementations. Sometimes its just faster to run 4 operations on a Pentium FPU than deal with the single, proper instruction through its ALU. I've seen and compared how fast interpolated, 32-bit integer math runs on a K6 (let alone an Athlon) compared to a Pentium III -- and the old K6 smokes it.
Please, please, stop any comparison, debate or otherwise general ignorant commentary on Intel's StrongARM microcontrollers versus their Pentium microprocessors. They are two very different breeds of products!
Here's some major design differences:
Speed v. Power: Pentium is sold at its top speed, irrespective of power usage (which varies little between speeds) -- plus Intel sells a separate, redesigned "mobile" line for when power becomes an issue. In contrast, the single StrongARM product series's speed is "scaled" up and down and power usage depends on its speed -- plus a 733MHz part uses 1.3W (an order of magnitude lower than even the mobile Pentium), and the 333MHz model only disapates around 0.5W (and there is an older StrongARM design that vary from 40-600MHz, which makes power usage fluctuate from as low as 0.04W to 450mW).
Superscalar v. Superpipelined: The Pentium is superscalar, with multiple pipelines (5-6 in most Pentium products, 8-20 stages each, depending on model) and uses advanced concepts like out-of-order execution and branch prediction to keeps its pipes full and executing. The StrongARM has but a single, 7-stage pipe that is kept full by a optimized compiler tuned for applications with fewer branchs and less interactive code.
[ Side note: the AMD Athlon uses 9 pipes. Which goes a long way to describing why a 9 pipe x 20 stage Athlon kicks the living crap out of a 6 pipe x 20 stage Pentium IV, MHz for MHz -- especially when combined with the fact that the Athlon only loses an average of 10 stages on a branch mis-predict, whereas all Pentiums have to flush all pipes -- a loss of all 20 stages on a Pentium IV. Even the 6 pipe x 10 stage Pentium III can handle itself against a Pentium IV -- more stages is usually less efficient and more troublesome (especially on branch mis-predicts), although required for OO, timing and other scalability issues. ]
Applications: Again, the applications the Pentium is used for is radically different than the StrongARM. In the case of the Pentium, most apps will require floating-point, whereas applications on the later usually do not. And the former can do 64/80-bit math, whereas the later can only do 32-bit. As far as multitasking, the later is great at multiple tasks and instruction rescheduling (again, micro"processor"), whereas the later is more akin to less random operations and control of data flow (again, micro"controller"). The StrongARM does NOT make an ideal, general-purpose CPU for heavy, multi-tasking workstations, but it does make a great, low-power CPU for support as well as standalone devices that only do a couple of things (or run only a couple of user apps simultaneously).
First off, please take note of the ISA (instruction set architecture) compatibility: it's 32-bit StrongARM! Of which, like ARM, is strictly a microcontroller without floating-point! So your "analysis" of Intel's design is from a standpoint of complete ignorance.
Again, this is a microcontroller, and NOT a general purpose "microprocessor." It's usually made for throwing data around in non-user devices like RAID controllers, backbone network switches (ones with lots of ports that require more than a basic ASIC, application specific integrated circuit), and the like. End-user devices make up only a fraction of the microcontroller market, and their integer-only functionality is quite sufficient.
And since it is only 32-bit, 32-bit interpolated integer math is just as good (or better) than 32-bit, single-precision floating-point for the end-user applications you mentioned. Besides, I was under the impression most handwriting recognition was image processing anyway, which is usually integer based. It has SIMD (single instruction, multiple data) that you'll find in general purpose microprocessor extensions like MMX and SSE. I cannot think of any application where you'd need the definition of 64-bit, or higher, double-precision outside of the range of non-science/engineering, end-user applications. 32-bit interpolated interger math is much faster than single-precision floating-point -- important for things like real-time speech recognition.
First off, your simplifying. But I'll get to that.
Secondly, just want to remind you who _did_ create the "great deficit". It was that nice Democratic Congress of 1982-1994. By lowering taxes, Reagan actually increased government income! Yet the Democrats saw fit to expand social programs greatly during his term ($3 for every new $1 in income). Look at the balance sheets.
The debt was only $1 Trillion as of 1986. By 1993 the debt had reached $4 Trillion.
A lot that was racked up by the Democrat Congress during those periods -- others due to increased defense spending under Reagan (but that was only 20% of the federal income, some 6% of the GNP, which includes all R&D that is NOT defense related -- still only about 1/3rd of social spending!!!). Yes, _some_ was due to the Gulf War, but not all of it.
We were headed for a recession and the it was actually made it worse by raising taxes in 1991-1992. It was Congress stupid, NOT Bush! He got pressured into signing it because the media was raking him over the coals every time the government "ran out of money" because he refused to sign the budget. A lose-lose situation for Bush -- yet the Democrats were totally to blame! You do NOT raise taxes during a recession!
So, then came to Clinton. The Deficit was $400B. Yes, he did reduce it to $240B in 1993. But that's all he was going to do. According to the Clinton 1993 budget, he was going to let the deficit creep upto $600B by 2000, with a total debt of $7 Trillion! All he did was a one-time cut. By early 1994, the Democrats had already let the deficit back up over $300B!
I got ahold of these balance sheets and projects in 1993. It wasn't until mid-1994 that the media took interest. As such, Clinton had to stall some spending and actually "clean up his act." Well, American didn't wait long to vote most of his spending buddies out.
So yes, the Democrat Congress did start changing its ways -- largely because of Clinton. But under the Republican Congress, even more things got going. You can say it was the economy, but the same damn "Democrat" "Economic Recovery Plan" was Bush's plan that got "stalled" from being past until after the 1992 election.
Very akin to what happened to Hoover when the Democrats controlled Congress in 1932. FDR's "New Deal" wasn't really any different than what the Republicans had in Congress, already!
Again, you cannot blame a single entity for it all. Just understand a Republican Congress really knows how to tighten its budget unlike the Democrats. I seriously think the best US government is a Republican Congress and a Democrat President -- at least until we get more Libertarians in there. As such, I really didn't care who won the election.
Active Directory has to be in charge of your network. That means you put all of your UNIX at 2000's mercy. Do NOT do it!
I'm currently writing a book on how to keep NT off your network -- completely! Using NIS and (in a future edition) LDAP. People think they must have a native PDC -- NOT TRUE! There is a lot you can do with NIS and NT. [ Note: I was a contributing author of Sam's "Samba Unleashed" by Steve Litt, who is actually a good friend of mine. I was also an original NT 3.1 beta tester and after 8 years of NT, finally chucked it "cold turkey" in mid-1999 because UNIX is just so much better for networks. ]
Again, do NOT put your network at the mercy of 2000 server! Once you do, your network is forever Microsoft controlled. Microsoft did this purposely. And even the IEEE has identified Windows 2000 and Active Directory as a "Threat to Internet Standards and Diversity".
Worse yet is when you put Exchange and SQL 2000 on that same network. Nuts! This really ties you down to MS-only solutions! Exchange is a pig that self-corrupts (you like those 48-hour straight downtimes, eh?)! Try Bynari TradeServer instead (flat $599 -- unlimited users, GTK+ management GUI, standards-based, LDAP-based, 100% Outlook Calendar/Contact compatible), plus they have a UNIX client that can interact with Outlook. So you save money *AND* get Internet standards -- a win-win!
I fight the ignorant on this every day (largely our admin/accounting departments). John Dvorak has pointed it out best (paraphrased), "Microsoft knows standalone PCs, but knows nothing about networking" urging Microsoft to just get out of the network/server business because it doesn't know crap (and Sun seems to be the opposite, good network, bad PC knowledge;-).
Democrats: "All Guns Should Come With Trigger Locks" -- because consumers are "too stupid" to decide for themselves whether or not to buy one of the numerous, existing handguns with a trigger lock
Open Source Software (OSS) -- you don't have to switch entirely over the Linux. Just try out various OSS programs for Windows -- keep your data out of proprietary application hands.
I'm sick of even "officiers" in my local LUGs, with users of 3+ years still running MS IE and Office (at meetings for God's sake!). God, could they please try StarOffice, or even the MS-IE-like KMelon browser? And there are many other application ports to Windows as well.
I write books and technical documentation just fine with LyX, which I switched to Word 97, from Word 95 and lost half my technical report styles. I had had enough of putting my data at risk with proprietary software. Never again, never again.
The people bitching the loudest are "so-called Linux advocates," who after years of running Linux for some niche purposes, haven't really spent a good 3 months using it as a serious desktop. They keep saying it is "not ready." I say BS! Get serious! Quit bitching.
I don't like Republicans any more than Democrats, but I'm sick of the common stigmas presented here. Pro-Democrats people like to talk about how the Republicans "ignore the issues," but never talk about how the Democrats spend a crapload of money on programs that do didley. And Democrats like to give Clinton credit, yet a simple glance at the balance sheets will tell you when and why the "recovery" started (happened in mid-1994 -- wonder why?;-).
I'm a voter registered "no party." And for good reasons. I vote mainly Libertarian, occassionally Republican, rarely Democrat. Let's face it, the federal government should not only stay out of most affairs, they can do little to affect them! I argue this against both sides, be it Republicans on "family values" or Democrats on "taxing the rich." Both are dead wrong.
Most Amercians live with the following ignorances that simple do NOT exist:
Republicans: "Liberals Are Bad" -- a mega-oversimplification of a single issue that is irrelevant to 90% of Americans
Republican: "Family Values" -- means I'm going to preach how you should live, yet half of us are hypocrites
Both: "Internet Filters" -- instead of arguing how to empower parents to filter content, Democrats and Republicans argue politically. All we need is a standardized framework so parents can choose who's list to subscribe to
Both: "School Prayer" -- another political arguement that is simply used to "hide" a "real issue" between conflicting parties in schools
Both: "Health Care" -- The real issue is that people who pay do NOT have choice! The government should allow you to get your health insurance pre-tax from anyone. I'd love to get it from the IEEE (as a member), but it is post-tax so I use my employer. [ And I clearly remember Hillary Clinton's proposal for "socialized medicine" was to take away the pre-tax benefit -- i.e. penalize those who pay for their own insurance!!! Fuck her on that one! ]
Both: "Tax Credits" -- Government handouts at the expense of others, creating yet more taxes
Democrats: "George W. will raise taxes like his father" -- Al Gore was one of the sponsors of that bill, let alone one of the political back-stabbers using the media to get it passed every time the government "ran out of money" because a new budget had not been passed (remember that in 1992? I did came election time!)
Democrats: "Tax Breaks for Millionaires" -- even more of a mega-oversimplification that people bad at basic economics like
Democrats: "Tax the Wealthy" -- there is a different between "wealthy" and "high income" -- you canNOT tax the former, only the later. So we canNOT tax millionaries who've already made their money with income tax (hence why the Democrats talk about how the richest pay little "income" tax) and we, instead, tax the middle to upper-middle class who funds most of this country. More political BS for those economically ignorant!
Democrats: "Trickle Down Theory Is Bad" -- everything is "trickle down", whether it goes through the government or private industry! [ more economic ignorance ]
Democrats: "Redistribution of Wealth" -- again, everything is "redistribution of wealth", whether it goes through the government or private industry! [ did I mention basic economics? ]
And there are many others. If you see things "my way"(TM), please respond and let it be known that you are sick of the stigmas of this whole Democrat v. Republican world.
90% of you'all are failing to remember that 90% of companies with a CTO are NOT IT-focused. One such type of company I can think of are engineering companies? And I'm sure there are other examples, like an accounting software firm (where the CTO would be familiar with tax codes, but the CIO would not need to be).
E.g., at my company, a fabless semiconductor (i.e. "computer chip") design firm, our CTO was the originator and developer of our patented asynchronous logic technology. This has 0% to do with IT (although end-user IT products will eventually benefit from it, but not directly inside our company). Although we are a small company without a CIO at this point, we will add one / promote one (hopefully me;-) when we grow past 200 employees or so with more than our current two offices.
Keeping with the traditional engineering example, understand that traditional engineering CTOs are usually formally educated (again, traditional engineering). The concepts and details of their technology requires this eduction, a foundation on differential equations, understanding of magnetic fields, signals, DSP, etc... to come up with new concepts and designs. Other engineering disciplines have theirs, as well as other, non-engineering fields.
I'm sure it differs at different firms or different types of firms. Still, I would see CTO and CIO as at the same level on the org chart. I don't see how either has anything to do with the other -- unless your firm is strictly an IT-focused firm (non-traditional software engineering / products).
Unless you have used Linux as a workstation, heavily, you shouldn't comment on what it can and cannot do. Some of us write books just fine with Linux, graphics, 3-D modeling, etc... And games support is very good, just as good as Windows 2000 (provided they make a Linux port).
I'm frankly sick of people who expect Linux applications to have good Office import filters, when Microsoft cannot even achieve such a feat with their own Mac ports and Works product. That should tell you something in where the problem lies (and it's not Linux;-).
-- Bryan "TheBS" Smith
Working in such an env., 10GB+, NT/UNIX clients
on
Clearcase vs. CVS?
·
· Score: 4
I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).
Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML). If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.
In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:
Use a UNIX server, for both repository and pserver (client/server, runs on port 2401 by default, setup in/etc/inetd.conf) daemon (recommend both be on the same system, although there are exceptions to this rule). The UNIX CVS server is just so much more flexible, although our SV office uses CVS on NT (but they are NT-only on the client side). Since most Linux distros come with the latest CVS software, stick with Linux for your server (the CVS server/repository should always have the same or later version than any client).
If performance is important, make sure your server has a lot of memory if you run pserver (again, client/server daemon on server's port 2401). When you do, the server needs 1.2-1.5x the memory of the largest file checked in, otherwise, thrasing will occur as you swap pages to/from memory. Again, I _highly_recommend_ you run pserver for access from NT clients.
On the UNIX side of things, you don't have to use pserver. You can directly access the repository via NFS mounts. This is slower, but, for large files, you do not run into the thrasing issue on the server. In a nutshell, pserver puts all the burden (incl. memory usage) of the diff/commit on the server, whereas clients that access the repository directly do all the work. Even though you run pserver (for your NT clients), you can still access the repository directly on UNIX clients.
Do *NOT* checkout via NT to the same directory as via UNIX. E.g., if/home = \\server\home, do not try to checkout to/home via UNIX and then commit via NT from \\server\home, or vice-versa. The reason for this is that while the repository is OS-independent, the checked out working directories have OS-specific details (e.g., drive letters when checked out via NT, which the UNIX cvs client won't understand -- plus LF/CR issues where NT gets the later automatically added). Either adopt one of two philosophies (or both, depending on your user):
If you need to have working files accessable in the same place from both NT and UNIX (e.g.,/home and \\server\home), then do all your cvs actions from the _UNIX_ side. The only issue you'll run into is any LF/CR that a Windows application would expect (since only LF will be used for line breaks since the working directory created/modified by UNIX). Since most of my Windows development tools don't mind LF-only breaks, I didn't have any problems with this.
The other philosophy involves a strict separation of working directories from NT and UNIX. Note, both clients still access the same, central repository and the same info. But when working, check out files via NT to a NT-only area and files via UNIX to a UNIX (possibly NT-also) area. This is what we also do with some people: Check out via NT to their local hard drive (which cuts down on network usage when they work), committing at the end of the day (for backup purposes), with other files being checked out to UNIX on the file server (and then accessable via both UNIX and, limited, NT over NFS/SMB shares -- which doesn't need to be committed at the end of the day since it gets backed up on the file server itself).
The use of each will depend on your workflow, possibly a per-user thing.
Be cautious about what you modify the CVS respository directly, but don't be shy to do it occassionally when you absolutely need to. This is what I love about CVS over other VC systems, a very understandable repository setup. Don't do it unless you cannot get a cvs client command to do what you want, don't do it reguarly and manually log anything you do to the repository for future reference. After a year and a half at my job, I have probably gone into the repository about 2-3 dozen times and haven't had any issues yet. Again, I haven't had such good luck with commercial systems and direct repository modification (when required).
Even if you are using a UNIX-only checkout environment, you can always use the nice, visual WinCVS client on the Windows side (provided you have a Samba share) to look at working file status (e.g., modified, current, etc...), but don't use to checkin/out UNIX working directories. If you are checking out via NT, then WinCVS will be a natural client choice. Just configure it for pserver, port 2401 and you'll be cooking.
[ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
Don't forget to set some basic variables in all your user scripts (or in a global script called at login), e.g.:
CVSUMASK 007 -- just like a regular umask, only for cvs checkouts
CVSREAD 1 -- set if you want to force users to do a "cvs edit" before editing a file (great for keeping track of concurrent edits/development), unset (or don't set) if you don't.
CVS_SERVER server and CVS_PASSFILE $HOME/private/.cvspass -- if you use pserver (client/server) access (or unset/don't set if you don't).
CVSROOT/home/cmroot/cvsroot or CVSROOT:pserver:$USER@server:/home/cmroot/cvsroot -- the former for direct repository access by client, the later to use pserver.
Also get some basic aliases down for your UNIX clients, e.g.:
alias cvs '/usr/local/bin/cvs -d/home/cmroot/cvsroot' -- accesses CVS repository/home/cdroot/cvsroot directory
alias cvs '/usr/local/bin/cvs -d:pserver:$USER@server:/home/cmroot/cvsroot' -- accesses CVS respository on SERVER at/home/cmroot/cvsroot via pserver (client/server)
alias noncvs "cvs -n -q update -I '! CVS' -r HEAD" -- List all non-current or unknown files in working directory from repository (I use this all the time)
alias noncvsi "cvs -n -q update -r HEAD -- same as previous, except apply ignored file list (which are listed in file $CVSROOT/CVSROOT/cvsignore -- which you'll want to checkout and modify for your site).
Do *NOT* make your server public. CVS is NOT a secure server, unless you use something like Kerberos client/server (instead of pserver, on a different port, I've never done this), or pserver with SSH as the remove shell. If you are going to run a publicly accessable CVS server, you'll want to run in at least pserver mode using SSH or, in the worst case, pserver with different usernames/passwords directly in the CVS admin files (rather than using the default of the local UNIX accounts). I highly recommend _against_ running a server that is both internally and externally accessable. If you need to, setup two separate servers, with two separate CVS repositories and run a cronjob to update the external server on a regular basis. Better yet, get familiar with "cvs export" on automating the export of files from the CVS repository (withOUT working CVS info) to archives, external servers, etc...
Lastly, if you have not adopted Cygnus' Cygwin GNU environment as standard on your NT desktops, do it now. No need to pay others for UNIX tools on NT, Cygwin is all you need. Do it even if you don't use GCC, and do all your development via Visual Studio, etc... There are just too many good UNIX CLI tools to ignore in there and you'll wish you'd had them. A CVS client is included (or you can use WinCVS').
[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC). VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1,:2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]
Slashdot Mirror
Logic synthesis tools are very important to modern day IC design and optimization.
That is why Theseus Logic, Inc. (mentioned about 2/3rds down in the NYTimes article) has a Strategic Alliance with Synopsys. Our patented NCL (Null Convention Logic) technology, unlike many other asynchronous technologies, is designed for maximum interoperability with existing tools, maximum design reuse and near-complete elimination of common CBL (clocked boolean logic) timing closure issues.
For those that mentioned Amulet, its project leader, as well as original ARM designer, Steve Furber is on Theseus' Advisory Board.
Please visit our web site for more information.
Disclaimer: I am an employee of Theseus Logic, Inc., who is NOT speaking on behalf of Theseus Logic in this post, nor his its content been approved by any Theseus Logic official.
-- Bryan "TheBS" Smith
The exception is where the course is mandated by the company to fill an immediate need.
You'd be surprised how many companies don't have that "exception." The ones that "require" you to be trained for your job, and expect you to reimburse them if you leave is utter bull. If my continued employment requires training, I expect the company to have no strings attached.
But if I get training that is not mandatory or required, they company should be able to "protect" their investment within reason. That is all your company is trying to do. If anything, company's should "pro-rate" the reimbursement, instead of making it a plateau date.
-- Bryan "TheBS" Smith
Blame the media for creating this "web of distrust" regarding the Internet. Don't get me wrong, your default attitude should be distrust when it comes to system security itself. But when you get someone on the line, in voice, or in a sincere correspondence, your first instinct should be to "thank" them. The great majority of people are quite ethical. Otherwise Melissa (and most of the original worms) would have wiped out most Windows systems on the first shot instead of just being a benign worm.
-- Bryan "TheBS" Smith
With the Quake series, idSoftware found the Intel 32-bit integer loads from memory to 32-bit general-purpose register to be piss-poor slow. With a little tinkering, they found that on the Pentium, loading two 32-bit integers into a 64-bit floating point register, and then moving those integers from register to register was much faster. Why? With the Pentium, Intel really worked hard on FPU to bring it up to more common RISC-implementation performance (the 80x87 ISA has always been a poor FPU implementation, remember Weitek? ;-), and created a well pipelined FPU in the Pentium (over other x86 processors at the time). Pipelining means that more than one instruction can be worked on by a unit simultaneously -- if similiar instructions follow one another.
Most fast, interpolated 3-D geometry usually involves sets of regularly, well-timed, memory loads of four to sixteen (4-16), 32-bit reads for each operand into registers (usually 1x4 or 4x4 matrix of 32-bit, interpolated integer coordinates in 3-D space). Again, loading through the traditional integer opcode was piss-poor slow -- and id, again, found that the new Pentium chip offered a "workaround" via its new, pipelined FPU.
Because this was "unorthodoxed", most compilers simply did not implement this. If you tried to read integers from memory, it would use the integer load opcode. So idSoftware had to write their own replacement memory read/write routines and functions. Undoubtably, this was done easiest in assembler.
BTW, this "Pentium optimization" was why the first generation of AMD and Cyrix processors lagged in Quake performance. Not because their FPU "sucked", but the idSoftware optimizations relied on the performance of a pipelined FPU -- not something AMD or Cyrix had in their first generation of Pentium ISA-compatible products. In fact, AMD's K6 (Nx686 core) had an excellent, non-pipelined FPU that was faster at execution -- provided your program was comprised of random integer/ALU, FPU and control opcodes. And if idSoftware would have just left the regular integer load in, the K6's integer memory load was upto 3x faster than the non-MMX Pentium and would have smacked the Pentium silly.
-- Bryan "TheBS" Smith
In most modern, general-purpose programs, assembler has rarely been used to "increase performance" over traditional program language code -- with rare exceptions going to heavily used functions that a profiler might pick up. And even then, most assembly is part of a larger program and a fraction of the total code -- usually in-line in the high-level language, or a self-containted object referenced by the other high-level language code. But even then, today's compilers are good optimizers and can even best you on your assembler if you don't know what you are doing.
No, for the past decade, assembler is still in use for raw, system-level details. Just like the Linux kernel, some things need to get done with GAS. Even NT's init loader is like this as well.
Most CS and engineering programs still teach assembler not to be proficient, but to understand the machine code v. man code relationship. It's not a full-up course where you write programs only in assembler -- in fact, I had a class on system-level programming where I wrote an assembler in C and binutils (lexx, awk, etc...). Why? It taught me not only assembler fundamentals, but the concepts of machine code and organization, basic parsing, hash tables, referencing and other concepts -- all in one course, in a very practical manner!
No, people why say "why code in assembler anymore?" are the people who continue to fail to understand why assembler ever existed. Heck, even Cobol and Fortran were available in the 50s! It was rarely a matter of "speed", but the fact that speed and size are "real-world constraints" at the system-level.
-- Bryan "TheBS" Smith
Forget that X-Windows source code rip with security issues (also known as "NT Terminal Server" ;-) and save some dough by just use a SSH client with port forwarding (like TeraTerm + TTSSH and VNC). It works great at my company, letting me support my notebook and other roaming users while they are on the road. TeraTerm+TTSSH is cake to setup, and you can configure it so all a user has to do is click an icon to connect with port forwarding.
-- Bryan "TheBS" Smith
First off, If you get anything out of this post it is this: DO NOT RUN A REDHAT X.0 RELEASE IF YOU DON'T UNDERSTAND LIBRARY VERSIONING
NO SUCH THING AS "GLIBC HELL"
There is _no_such_thing_ as "glibc Hell". UNIX (including Linux) has versioning on libraries -- right down tot he filename. _Unlike_ Windows, you can have _multiple_library_versions_ installed. Even Microsoft still has NOT addressed this (and I run into it daily) simply by versioning filenames of libraries. This is a _farce_ and the result of people not understanding the OS in front of them.
UNIX v. WINDOWS ON SYSTEM LIBRARIES
So, in a nutshell, you can have your library issues two ways:
- Recompile for new libraries (if you have source)
Otherwise, no option if you don't have source -- total SOL!Especially on Win2K which makes some libraries untouchable (and quite incompatible with a lot of existing software).
Microsoft does this for "stability", but it is a library- ignorant way of NOT addressing the _real_ issue, lib versioning.
LIBRARY VERSIONING AND SYMBOLIC LINKS
The main reason Windows cannot have UNIX-like library versioning and versioning on filenames is because it lacks symbolic links. With symbolic links, you can have multiple subrevision of a library, with one subrevision the "default" revision, with that (or another) the default "main" version. E.g.,:
libmy.so -> libmy.so.1
libmy.so.1 -> libmy.so.1.1
libmy.so.1.0 -> libmy.so.1.0.7
libmy.so.1.0.7
libmy.so.1.1 -> libmy.so.1.1.3
libmy.so.1.1.2
libmy.so.1.1.3
libmy.so.3 -> libmy.so.3.0
libmy.so.3.0 -> libmy.so.3.0.1
libmy.so.3.0.1
In the preceding example, there are actually only 4 library versions: 1.0.7, 1.1.2, 1.1.3 and 3.0.1. We could easily introduce more versions if programs required them. Most libraries are "parent revisioned" (I don't know what the "official term" is, but that's what I'll call it), so the latest "x.y.z" "version.revision.subrevision" is synlinked as "x.y" "version.revision" as well as "x" "version". As far as compatility between versions, anything goes (and is a per-library consideration), but the "general rule" is as follows:
Most OSS projects, including GLibC, have good versioning schemes that change subrevisions (the "Z" in x.y.z when updates, bugfixes, or non-structural changes are made -- meaning 1.1.2 and 1.1.3 are most likely header/function compatible. So, depending on the library, most programs are fine when linking against X.Y instead of x.y.z-- and do so to keep from requiring the user to have numerous differnet libraries installed. A simple x.y symlink to the latest x.y.z (latest being the max(Z)) is usually all it takes. Again, a "parent revision" symlink does the job.
Now different revisions (the "Y" in x.y.z) usually involve some header/function changes that _may_ be INcompatible. As such vendors usually do not link against just the major version (the "X" in x.y.z) for that reason. E.g., some programs work fine on any GLibC 2.y.z system (BTW, GLibC 2 is aka LibC 6), but most are tied to GLibC 2.0.z (RedHat 5.x), GLibC 2.1.z (RedHat 6.x) or GLibC 2.2.z (RedHat 7.x). Major version changes (again, the "X" in x.y.z) are left for radical, completely incompatible changes -- like LibC 4 (RedHat 3.x), LibC 5 (RedHat 4.x) and GLibC 2 (RedHat 5.x+ -- which caused a bigger stir than 7.0 awhile back ;-PPP).
DON'T RUN A REDHAT X.0 RELEASE UNLESS YOU KNOW WHAT YOU ARE DOING!
98% of the "bitching and moaning" about RedHat 7.0 comes from user naivity on library versioning. Yes, I _do_agree_ that RedHat did release 7.0 too earlier with unfinished components, but since patching GLibC and GCC through December, RedHat 7.0 is a _solid_ release. Never, never adopt a RedHat X.0 release unless you are a seasoned Linux user! Please get the word out on that (although the RedHat 7.0 README on CD 1 *DOES* stress that point too!!!)
[ Side note: The kernel is another matter though -- but understand RedHat cannot "time" the release of GLibC, GCC and the kernel since they are all independent development teams. ]
RedHat gives you _full_warning_ of the all-important GLibC change in a new release. It's always been RedHat's model -- introduce a new, and possibly INcompatible GLibC on a X.0 release. All revisions in a major release have the same GLibC and GCC, and are quite interchangable. I've said it before and I'll say it again, only RedHat seems to do this (although I haven't checked out Debian yet). So I know that going from 6.2 to 7.0 means issues, just like 4.2 to 5.0 did for me almost a half-decade ago. NOTHING NEW!
So, again, if you do NOT know what you are doing, stick with RedHat X.2 releases (or at least X.1)!!! At X.0 releases, most of the Linux world has NOT yet adopted the new GLibC versions -- hence the wealth of binary library incompatibilities. So if you are not familiar with how to deal with them, do NOT try to deal with a RedHat X.0 release!
REDHAT MAINTAINS LIBRARY COMPATIBILITY
Today's RedHat 7.0 (GLibC 2.2) release comes with full RedHat 6.x (GLibC 2.1) compat libs, even a compat devel libs and a compat compiler/linker. And you can also install compat libs from the RedHat 6.2 release for 4.x (LibC 5) and 5.x (GLibC 2.0) compatibility.
[ Side note: I *DO* have a "complaint" with RedHat for not including LibC5 and GLibC2.0 compatibility libraries with RedHat 7.0. And I've let Alan Cox know about them. They should _at_least_ be available on the Powertools CD. I know LibC4 shouldn't be included for security reasons, but LibC5 and, especially, GLibC2.0 should be! ]
ANY LIBRARY ISSUES ARE ALMOST ALWAYS THE PACKAGERS FAULT!
Now that we have the user out of the way, as long as a vendor/packager dynamically links against the specific library version, the binary will use that version. Too many vendors are used to just linking against what they have, especially if it is an older library on their development system. So when a user has a new version of the library, possible with function name, parameter and other structrual changes, core dumps will occur.
If a developer is really worried, there is always the option of statically linking -- i.e. putting the library in the binary itself (so no external library references/dependencies). Of course, there could be licensing issues with GPL or other OSS code to/from commerical and vice-versa. If people think this is limited to Linux, they are _gravely_mistaken_ as most commercial IDE and development tools introduce their own issues. Under Windows, where only one system library can be installed (and that library may be "fixed" in Win2K), you're in for a world of hurt trying to sort them out.
END-USER LIBRARY VERSION ADMINISTRATION
As previously discussed, symlinks are often used to "parent revision" a full "x.y.z" "version.revision.subrevision". Most of the time, RPMS and tarballs/makes installs do this for you. But sometimes, you'll have to administer and create them yourself. Again, doing this is usually easy (it's just a symlink -- "ln -s ") and the first thing to try when a program cannot find a library (e.g., libmy-2.0) where a library exists with a more complete version (e.g., libmy-2.0.1).
-- Bryan "TheBS" Smith
GnomeOffice Dia is a UML-based diagramming and vector graphics app. You can extend it with XML/UML (and conforms to the full UML spec as defined by its XML DTD) and it supports a plethora of standard graphics formats for inport and export. There are numerous documents on the web that use Dia as an example of learning XML/UML programming to a DTD spec.
-- Bryan "TheBS" Smith
I work for a fabless semiconductor design firm and we are almost entirely UNIX-based. We use Innoveda ViewLogic (see products associated with ViewDraw) for our schematic capture. At my previous employer, an aerospace firm, we also used ViewLogic for PCB Layout.
The only kicker is that ViewLogic is expensive for the UNIX version. As such, even we run the Windows version on some. But everything else, our Cadence, Mentor Graphics, Modeltech and Synopsys tools all run on either Solaris or, increasingly, Linux (as more and more vendors offer then).
-- Bryan "TheBS" Smith
Yes, there *IS* a lot of "overlap" between the applications of the two. Regardless, my original statements hold true on how and who for the Pentium microprocessor is designed versus how and who for the StrongARM microcontroller is designed.
Microprocessors range from simplistic, single-issue CPUs to the nine-issue, massively buffered K7. Microcontrollers range from basic 8-bit cores to the 32-bit superpipelined StrongARM with external, co-processor options.
Your application will be the best judge of what to use.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
More importantly, the context of this posting is that someone booted Linux on it and that people built PDAs based on this processor, so it's not just being used as an I/O controller for RAIDs.
Yes. But, and I hope you agree with:
On most modern processors, you actually often get faster performance if you implement using FP because integer arithmetic (for loops and indexes) and FP arithmetic can happen in parallel.
A well informed post, greatly appreciate the insight. So now I ask:
-- Bryan "TheBS" Smith
Please, please, stop any comparison, debate or otherwise general ignorant commentary on Intel's StrongARM microcontrollers versus their Pentium microprocessors. They are two very different breeds of products!
Here's some major design differences:
[ Side note: the AMD Athlon uses 9 pipes. Which goes a long way to describing why a 9 pipe x 20 stage Athlon kicks the living crap out of a 6 pipe x 20 stage Pentium IV, MHz for MHz -- especially when combined with the fact that the Athlon only loses an average of 10 stages on a branch mis-predict, whereas all Pentiums have to flush all pipes -- a loss of all 20 stages on a Pentium IV. Even the 6 pipe x 10 stage Pentium III can handle itself against a Pentium IV -- more stages is usually less efficient and more troublesome (especially on branch mis-predicts), although required for OO, timing and other scalability issues. ]
-- Bryan "TheBS" Smith
First off, please take note of the ISA (instruction set architecture) compatibility: it's 32-bit StrongARM! Of which, like ARM, is strictly a microcontroller without floating-point! So your "analysis" of Intel's design is from a standpoint of complete ignorance.
Again, this is a microcontroller, and NOT a general purpose "microprocessor." It's usually made for throwing data around in non-user devices like RAID controllers, backbone network switches (ones with lots of ports that require more than a basic ASIC, application specific integrated circuit), and the like. End-user devices make up only a fraction of the microcontroller market, and their integer-only functionality is quite sufficient.
And since it is only 32-bit, 32-bit interpolated integer math is just as good (or better) than 32-bit, single-precision floating-point for the end-user applications you mentioned. Besides, I was under the impression most handwriting recognition was image processing anyway, which is usually integer based. It has SIMD (single instruction, multiple data) that you'll find in general purpose microprocessor extensions like MMX and SSE. I cannot think of any application where you'd need the definition of 64-bit, or higher, double-precision outside of the range of non-science/engineering, end-user applications. 32-bit interpolated interger math is much faster than single-precision floating-point -- important for things like real-time speech recognition.
-- Bryan "TheBS" Smith
First off, your simplifying. But I'll get to that.
Secondly, just want to remind you who _did_ create the "great deficit". It was that nice Democratic Congress of 1982-1994. By lowering taxes, Reagan actually increased government income! Yet the Democrats saw fit to expand social programs greatly during his term ($3 for every new $1 in income). Look at the balance sheets.
The debt was only $1 Trillion as of 1986. By 1993 the debt had reached $4 Trillion. A lot that was racked up by the Democrat Congress during those periods -- others due to increased defense spending under Reagan (but that was only 20% of the federal income, some 6% of the GNP, which includes all R&D that is NOT defense related -- still only about 1/3rd of social spending!!!). Yes, _some_ was due to the Gulf War, but not all of it.
We were headed for a recession and the it was actually made it worse by raising taxes in 1991-1992. It was Congress stupid, NOT Bush! He got pressured into signing it because the media was raking him over the coals every time the government "ran out of money" because he refused to sign the budget. A lose-lose situation for Bush -- yet the Democrats were totally to blame! You do NOT raise taxes during a recession!
So, then came to Clinton. The Deficit was $400B. Yes, he did reduce it to $240B in 1993. But that's all he was going to do. According to the Clinton 1993 budget, he was going to let the deficit creep upto $600B by 2000, with a total debt of $7 Trillion! All he did was a one-time cut. By early 1994, the Democrats had already let the deficit back up over $300B!
I got ahold of these balance sheets and projects in 1993. It wasn't until mid-1994 that the media took interest. As such, Clinton had to stall some spending and actually "clean up his act." Well, American didn't wait long to vote most of his spending buddies out.
So yes, the Democrat Congress did start changing its ways -- largely because of Clinton. But under the Republican Congress, even more things got going. You can say it was the economy, but the same damn "Democrat" "Economic Recovery Plan" was Bush's plan that got "stalled" from being past until after the 1992 election.
Very akin to what happened to Hoover when the Democrats controlled Congress in 1932. FDR's "New Deal" wasn't really any different than what the Republicans had in Congress, already!
Again, you cannot blame a single entity for it all. Just understand a Republican Congress really knows how to tighten its budget unlike the Democrats. I seriously think the best US government is a Republican Congress and a Democrat President -- at least until we get more Libertarians in there. As such, I really didn't care who won the election.
-- Bryan "TheBS" Smith
This guy is a Solaris admin. As such, he needs to be concerned what Win2k/AD will do to his Solaris boxen!
Geez, get your freak'n heads out of the Windows-only clouds! Some of us have applications that are Linux and Solaris-only on our networks!!!
-- Bryan "TheBS" Smith
BIG MISTAKE DUDE!
Active Directory has to be in charge of your network. That means you put all of your UNIX at 2000's mercy. Do NOT do it!
I'm currently writing a book on how to keep NT off your network -- completely! Using NIS and (in a future edition) LDAP. People think they must have a native PDC -- NOT TRUE! There is a lot you can do with NIS and NT. [ Note: I was a contributing author of Sam's "Samba Unleashed" by Steve Litt, who is actually a good friend of mine. I was also an original NT 3.1 beta tester and after 8 years of NT, finally chucked it "cold turkey" in mid-1999 because UNIX is just so much better for networks. ]
Again, do NOT put your network at the mercy of 2000 server! Once you do, your network is forever Microsoft controlled. Microsoft did this purposely. And even the IEEE has identified Windows 2000 and Active Directory as a "Threat to Internet Standards and Diversity".
Worse yet is when you put Exchange and SQL 2000 on that same network. Nuts! This really ties you down to MS-only solutions! Exchange is a pig that self-corrupts (you like those 48-hour straight downtimes, eh?)! Try Bynari TradeServer instead (flat $599 -- unlimited users, GTK+ management GUI, standards-based, LDAP-based, 100% Outlook Calendar/Contact compatible), plus they have a UNIX client that can interact with Outlook. So you save money *AND* get Internet standards -- a win-win!
I fight the ignorant on this every day (largely our admin/accounting departments). John Dvorak has pointed it out best (paraphrased), "Microsoft knows standalone PCs, but knows nothing about networking" urging Microsoft to just get out of the network/server business because it doesn't know crap (and Sun seems to be the opposite, good network, bad PC knowledge ;-).
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Agreed.
Open Source Software (OSS) -- you don't have to switch entirely over the Linux. Just try out various OSS programs for Windows -- keep your data out of proprietary application hands.
I'm sick of even "officiers" in my local LUGs, with users of 3+ years still running MS IE and Office (at meetings for God's sake!). God, could they please try StarOffice, or even the MS-IE-like KMelon browser? And there are many other application ports to Windows as well.
I write books and technical documentation just fine with LyX, which I switched to Word 97, from Word 95 and lost half my technical report styles. I had had enough of putting my data at risk with proprietary software. Never again, never again.
The people bitching the loudest are "so-called Linux advocates," who after years of running Linux for some niche purposes, haven't really spent a good 3 months using it as a serious desktop. They keep saying it is "not ready." I say BS! Get serious! Quit bitching.
-- Bryan "TheBS" Smith
I don't like Republicans any more than Democrats, but I'm sick of the common stigmas presented here. Pro-Democrats people like to talk about how the Republicans "ignore the issues," but never talk about how the Democrats spend a crapload of money on programs that do didley. And Democrats like to give Clinton credit, yet a simple glance at the balance sheets will tell you when and why the "recovery" started (happened in mid-1994 -- wonder why? ;-).
I'm a voter registered "no party." And for good reasons. I vote mainly Libertarian, occassionally Republican, rarely Democrat. Let's face it, the federal government should not only stay out of most affairs, they can do little to affect them! I argue this against both sides, be it Republicans on "family values" or Democrats on "taxing the rich." Both are dead wrong.
Most Amercians live with the following ignorances that simple do NOT exist:
And there are many others. If you see things "my way"(TM), please respond and let it be known that you are sick of the stigmas of this whole Democrat v. Republican world.
-- Bryan "TheBS" Smith
Damn that was too simple, yet it was right on the money and perfect. Saves on the virtual trees too. ;-P
-- Bryan "TheBS" Smith
90% of you'all are failing to remember that 90% of companies with a CTO are NOT IT-focused. One such type of company I can think of are engineering companies? And I'm sure there are other examples, like an accounting software firm (where the CTO would be familiar with tax codes, but the CIO would not need to be).
E.g., at my company, a fabless semiconductor (i.e. "computer chip") design firm, our CTO was the originator and developer of our patented asynchronous logic technology. This has 0% to do with IT (although end-user IT products will eventually benefit from it, but not directly inside our company). Although we are a small company without a CIO at this point, we will add one / promote one (hopefully me ;-) when we grow past 200 employees or so with more than our current two offices.
Keeping with the traditional engineering example, understand that traditional engineering CTOs are usually formally educated (again, traditional engineering). The concepts and details of their technology requires this eduction, a foundation on differential equations, understanding of magnetic fields, signals, DSP, etc... to come up with new concepts and designs. Other engineering disciplines have theirs, as well as other, non-engineering fields.
I'm sure it differs at different firms or different types of firms. Still, I would see CTO and CIO as at the same level on the org chart. I don't see how either has anything to do with the other -- unless your firm is strictly an IT-focused firm (non-traditional software engineering / products).
-- Bryan "TheBS" Smith
Unless you have used Linux as a workstation, heavily, you shouldn't comment on what it can and cannot do. Some of us write books just fine with Linux, graphics, 3-D modeling, etc... And games support is very good, just as good as Windows 2000 (provided they make a Linux port).
I'm frankly sick of people who expect Linux applications to have good Office import filters, when Microsoft cannot even achieve such a feat with their own Mac ports and Works product. That should tell you something in where the problem lies (and it's not Linux ;-).
-- Bryan "TheBS" Smith
I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).
Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML). If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.
In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:
[ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC). VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1, :2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]
-- Bryan "TheBS" Smith
FYI, ZDNet has an article here.
-- Bryan "TheBS" Smith