The whole.Net framework completely overturns the way you developed applications for Windows. It's really quite incredible, just from a developer productivity standpoint.
I'll believe it when I see it in action, not hype.
They claim they support ECC SDRAM, but they don't. Their motherboards run ECC SDRAM, but don't actually use the ECC hardware. See http://cr.yp.to/hardware/abit.html
They claim they support ECC SDRAM, but they don't. Their motherboards run ECC SDRAM, but don't actually use the ECC hardware. See http://cr.yp.to/hardware/abit.html
These are under $300 on Ebay, work great, and have many features. You'll have better compatibility experience with AMI cards, Mylex have more features though, but older eXtremeRAID have proprietary memory modules (which will cost $1000 retail if you want upgrade, if you find one somewhere).
ICP Vortex have great reputation, though I don't have any experience with them.
What a snob this guy is. FreeBSD could learn from ReiserFS, and viceversa. Furthermore, ReiserFS is not clunky, slow, or unstable (this was true a year ago with some versions). This is a type of fuddery you usually see from MS.
Instead of blatent factless FUD, why couldn't Hubbard just simply summarize technical advantages/disadvantages of softupdates and a journaling FS like ReiserFS? I think they just can't admit the fact of some filesystems' superiority (regardless of Linux distributions' duct tape "trainwreck" nature), and the lack of journaling support in *BSD. Softupdates can still lose data where journaling won't. They're unsuitable in situations where data must be written atomically, like SMTP servers. Then they wonder why *BSD has such small commercial backing - snobbery and prima donnas.
And a functional language makes this even easier with pattern matching where a different function is executed if it matches a set of parameters, for example:
His question is specific to OO, but anyway: one of the reasons why stuff like that is not solved using OO languages is probably because they don't offer much of the requirements for these problems.
His, problems IMHO scream "GIVE ME A FUNCTIONAL LANGUAGE". Some functional languages semantically and syntactically resemble calculus and offer features that are better at helping solving engineering problems at hand. Take a look at Haskell or Erlang (a heavy-duty language proven by telecom industry) for example.
Simple syntax, easy to learn (very few keywords), very few side-effects and you probably don't want a mechanical engineer to worry about memory allocation either.
I would think these exceed an engineer's requirements over C++ or Java for solving many problems (not all): garbage collection of course, massive concurrency (thousands of threads in one instance of a virtual machine in Erlang for example is no problem) as part of the language, exceptions handling, built-in interprocess communication, pattern matching (polymorphism), resizable lists and tuples, tail-call recursion, modules, hot code updates on running systems, etc., etc. And no OO to get in the way. These help you concentrate on _what_ to solve at hand, instead of _how_ to solve your problems (memory allocation, OO, etc.). You leave most of _how_ to the language, and worry about the problem, not language. Similar to working with Mathematica or Maple, except on a much larger scale.
These languages are great for higher-level logic that's very tough to do in lower-level languages like C or C++. They can be interfaced to C or other languages for performance-critical, or device drivers etc. needs. Bottom line: writing software for many engineering problems in functional languages should be easier, because they were designed for some of those specific purposes (like Ericsson's AXD switch).
Also, one thing to remember is it's your big money and time spent to get that paper. AFAIK most universities couldn't give a rat's ass about quality of their programs (as all they usually care about is your money *cough* Drexel, *cough*). Most don't educate you, they just collect money and issue the paper at the end. Most of your time is spent getting grades, not quality education.
You are quite on your own at a university. Many of them are overcrowded, and beaureaucracy is unbelievable. We, for example didn't have computers in computer classes, and some people had to sit on stairs. The computer labs were overcrowded, and it was impossible to achieve lab objectives in alotted time. It was a fucking rat race. Essentialy you read books and tried to score on tests. There was simply not enough time to grasp subjects and theory as deep as one would need.
The best education you can get is by yourself from yourself. Just like Mark Twain said, schooling and education are different. They school you; you educate yourself. So at least go to a university that's as close to worthwhile as possible.
In my personal experience computer-related courses are of much higher quality at community colleges than universities. Bottom line: university gives you a ticket to get a job, just because it's a social thing. Many of these CS graduates are cluebies, because again they were just passing tests (and some I know cheated a lot). It's a scam.
No, TDS is tabular data stream protocol. M$ dumbed it down, and gave it a new version number in 7.0. You can still talk from *nix using FreeTDS libraries which is what we're doing.
Wrong. MS SQL 6.5 is a ported version of Open Server. 7.0 just changed TDS protocol. 7.0 is not a 5-year old product. The bulk of the code is still Sybase. It's Sybase design and Sybase code, not MS.
You might sing its praises, but it's still an administrators' nightmare for at least one reason: one large database file. Corrupt the file, kill the system. How dumb.
Properly-designed software stores each message in a separate file for reliability - maildir.
Curse for reliability purposes too. Corrupt one file, means corrupt everyone's email. Exchange is an administrator's nightmare.
Store each message in its own file, on a good file system with better software if you want reliability. Qmail or Postfix or Curier and good *nix would do great. Also there's the qmail-ldap patch, which works great for centrallized administration and clustering.
This is not true for all *nix-based email systems. Qmail can be configured with a bulletin system that just creates a symbolic link to a message from every mailbox. And as far as I know, symbolic links didn't even exist in wintendo world till w2k.
Having one huge file to store all email is a piss-poor design. The problem is inherent, and well-known. Corrupted Exchange databases are a frequent MCSE nightmare.
Slashdot Mirror
The whole .Net framework completely overturns the way you developed applications for Windows. It's really quite incredible, just from a developer productivity standpoint.
I'll believe it when I see it in action, not hype.
They claim they support ECC SDRAM, but they don't. Their motherboards run ECC SDRAM, but don't actually use the ECC hardware. See http://cr.yp.to/hardware/abit.html
They claim they support ECC SDRAM, but they don't. Their motherboards run ECC SDRAM, but don't actually use the ECC hardware. See http://cr.yp.to/hardware/abit.html
These are under $300 on Ebay, work great, and have many features. You'll have better compatibility experience with AMI cards, Mylex have more features though, but older eXtremeRAID have proprietary memory modules (which will cost $1000 retail if you want upgrade, if you find one somewhere).
ICP Vortex have great reputation, though I don't have any experience with them.
Wow a troll gets this high rating?
Small software has no problems being written in C though. The problem is lack of modularity in large software which leads to hard-to-find bugs.
Network Failure System.
And they bought it from someone (Interix?).
What a snob this guy is. FreeBSD could learn from ReiserFS, and viceversa. Furthermore, ReiserFS is not clunky, slow, or unstable (this was true a year ago with some versions). This is a type of fuddery you usually see from MS.
Instead of blatent factless FUD, why couldn't Hubbard just simply summarize technical advantages/disadvantages of softupdates and a journaling FS like ReiserFS? I think they just can't admit the fact of some filesystems' superiority (regardless of Linux distributions' duct tape "trainwreck" nature), and the lack of journaling support in *BSD. Softupdates can still lose data where journaling won't. They're unsuitable in situations where data must be written atomically, like SMTP servers. Then they wonder why *BSD has such small commercial backing - snobbery and prima donnas.
And a functional language makes this even easier with pattern matching where a different function is executed if it matches a set of parameters, for example:
:-)
-module(mathStuff).
-export([factorial/1, area/1]).
factorial(0) -> 1;
factorial(N) -> N * factorial(N-1).
area({square, Side}) ->
Side * Side;
area({circle, Radius}) ->
% almost
3 * Radius * Radius;
area({triangle, A, B, C}) ->
S = (A + B + C)/2,
math:sqrt(S*(S-A)*(S-B)*(S-C));
area(Other) ->
{invalid_object, Other}.
His question is specific to OO, but anyway: one of the reasons why stuff like that is not solved using OO languages is probably because they don't offer much of the requirements for these problems.
His, problems IMHO scream "GIVE ME A FUNCTIONAL LANGUAGE". Some functional languages semantically and syntactically resemble calculus and offer features that are better at helping solving engineering problems at hand. Take a look at Haskell or Erlang (a heavy-duty language proven by telecom industry) for example.
Simple syntax, easy to learn (very few keywords), very few side-effects and you probably don't want a mechanical engineer to worry about memory allocation either.
I would think these exceed an engineer's requirements over C++ or Java for solving many problems (not all): garbage collection of course, massive concurrency (thousands of threads in one instance of a virtual machine in Erlang for example is no problem) as part of the language, exceptions handling, built-in interprocess communication, pattern matching (polymorphism), resizable lists and tuples, tail-call recursion, modules, hot code updates on running systems, etc., etc. And no OO to get in the way. These help you concentrate on _what_ to solve at hand, instead of _how_ to solve your problems (memory allocation, OO, etc.). You leave most of _how_ to the language, and worry about the problem, not language. Similar to working with Mathematica or Maple, except on a much larger scale.
These languages are great for higher-level logic that's very tough to do in lower-level languages like C or C++. They can be interfaced to C or other languages for performance-critical, or device drivers etc. needs. Bottom line: writing software for many engineering problems in functional languages should be easier, because they were designed for some of those specific purposes (like Ericsson's AXD switch).
Also, one thing to remember is it's your big money and time spent to get that paper. AFAIK most universities couldn't give a rat's ass about quality of their programs (as all they usually care about is your money *cough* Drexel, *cough*). Most don't educate you, they just collect money and issue the paper at the end. Most of your time is spent getting grades, not quality education.
You are quite on your own at a university. Many of them are overcrowded, and beaureaucracy is unbelievable. We, for example didn't have computers in computer classes, and some people had to sit on stairs. The computer labs were overcrowded, and it was impossible to achieve lab objectives in alotted time. It was a fucking rat race. Essentialy you read books and tried to score on tests. There was simply not enough time to grasp subjects and theory as deep as one would need.
The best education you can get is by yourself from yourself. Just like Mark Twain said, schooling and education are different. They school you; you educate yourself. So at least go to a university that's as close to worthwhile as possible.
In my personal experience computer-related courses are of much higher quality at community colleges than universities. Bottom line: university gives you a ticket to get a job, just because it's a social thing. Many of these CS graduates are cluebies, because again they were just passing tests (and some I know cheated a lot). It's a scam.
I was talking about storing mail on the file system, where it belongs, not a database.
Bah, we're not even using 2000. We're still with 7.0.
No, TDS is tabular data stream protocol. M$ dumbed it down, and gave it a new version number in 7.0. You can still talk from *nix using FreeTDS libraries which is what we're doing.
I am sure the core is still Sybase. You can talk to MSSQL if you have Sybase or FreeTDS libraries.
Wrong. MS SQL 6.5 is a ported version of Open Server. 7.0 just changed TDS protocol. 7.0 is not a 5-year old product. The bulk of the code is still Sybase. It's Sybase design and Sybase code, not MS.
You might sing its praises, but it's still an administrators' nightmare for at least one reason: one large database file. Corrupt the file, kill the system. How dumb.
Properly-designed software stores each message in a separate file for reliability - maildir.
Half-a-gig of RAM for 140 Users? My 16 MB BSD box can do multitudes better. Piss poor!
The IMAP server of choice for Qmail is Courier-IMAP (Maildirs, LDAP authentication, blah blah).
www.courier-mta.org
The bulletin program is here: www.coker.com.au/maildir-bulletin/
Curse for reliability purposes too. Corrupt one file, means corrupt everyone's email. Exchange is an administrator's nightmare.
Store each message in its own file, on a good file system with better software if you want reliability. Qmail or Postfix or Curier and good *nix would do great. Also there's the qmail-ldap patch, which works great for centrallized administration and clustering.
Which M$ couldn't design themselves, and bought it from Sybase.
This is not true for all *nix-based email systems. Qmail can be configured with a bulletin system that just creates a symbolic link to a message from every mailbox. And as far as I know, symbolic links didn't even exist in wintendo world till w2k.
Having one huge file to store all email is a piss-poor design. The problem is inherent, and well-known. Corrupted Exchange databases are a frequent MCSE nightmare.
Modern gas engines are only about 20% efficient.
A little more with turbo.
This guy will be inventing new ways to cover-up MS holes, and establish better MS image within U.S. government. What else?
"Cingular". Corporate identity bullshit can't get any worse than this. Oh wait... "Verizon".