That's news to me. I know Haskell has things like "type classes" and a very smart type inferencer, but that doesn't make it dynamically typed, does it?
That's disgracing, but it doesn't invalidate my point (provided the "lack of respect" the OP mentioned referred to the French government's criticism of the war). The question is whether the French government shows a "lack of respect" for American soldiers in WWII by criticising US policy of 2003. Which I think it doesn't.
Who cares what france does.. What pisses me off is the lack of respect they showed the US after 150,000 of our guys died liberating that dumbass country.
The notion that criticizing the US has anything to do with showing disrespect for what US soldiers did in WWII is devious.
How about we focus on getting things out into space first, then we worry about being able to get pr0n to them?
Well, since most geeks don't build spacecrafts, and most space technicians don't design network protocols, we might as well work in parallel and do all at once:).
You don't need special features like you suggest in a filesystem to manage your files properly.
When you're dealing with gigabytes and gigabytes of data, yes, you do.
I doubt that any single person, let alone "Grandma", will ever manage "gigabytes and gigabytes" of highly structured data.
I'm an awfully untidy person (my home directory looks just as cluttered as my workroom), yet even I don't have any problems locating my project files or my photo collection.
If you really need to manage huge amounts of structured data, you may as well use an SQL database.
And performing search operations on such databases will only be fast if there is an index for the key(s) the search is based on. That is, at some point you'll have to anticipate the ways your data will eventually be used. Structuring data is a non-trivial task.
Btw, does anybody use the "indexing" feature of MS Office?
I wonder how many years it will take for Linux to play catchup to these kinds of features that I imagine will be commonplace by the time 2005 rolls around.
You can have database-like filesystems on Unix today. You can't on Windows.
And these features are in no way new; they have been "commonplace" in other OSes years ago.
Heck, I'm still holding my breath for a hardware accelerated X replacement, but the Linux zealots are too afraid of change for that to happen anytime soon...
WTF are you talking about? X has its problems, but it supports hardware acceleration.
I just downloaded the book from http://members.aol.com/Seb0013/uhh.pdf. acroread 4 on Linux (Debian testing) tells me that "there was an error opening this document (14)." acroread 5 says that "the file is damaged but is being repaired", and then keeps on "repairing" forever, using up all available CPU time.
xpdf 1.00 reports
Error (0): PDF file is damaged - attempting to reconstruct xref table... Error: Top-level pages object is wrong type (null) Error: Couldn't read page catalog
the MD5 checksum of the file is 60d0746053d204477d40e74c19a6aea2.
Re:Sysadmin view - could be useful
on
Linus on DRM
·
· Score: 1
Ok, so suppose there is a working DRM implementation in the kernel.
I work as a sysadmin, providing desktop services on unix systems. Something like this would be great!
I could sign all binaries that I trust to run with root privileges, and as long as my private key is safe, running unknown binaries as root becomes impossible.
This will make root exploits somewhat more difficult, and if the BIOS supports it too, hacking the system with boot floppies/netboot etc. will be really hard.
Think about it.
I think that if you want such features, it would be more convenient to implement them in the kernel, without special hardware support. On Linux, RSBAC might be a good starting point.
Simple... suddenly secure Office apps will use.Net which runs the macros in a sandbox outside the secure zone.
I see. M$ will try to improve security by using 30-years-old techniques like sandboxing, and then sell that to us as if Palladium had made it all possible in the first place. Clever, I'll admit.
But the more obvious step would be to prohit you from manually launching such a script in the first place.
, lauching it automatically instead?
You might even *want* macros to have access to some of your data in order for them to be useful.
But this sort of thing is brilliant for companies, as it cuts down on the damage a employee can do on their PC.
You can "lock down" current systems quite well. One could even think of building more restrictive security checks into the kernel. No need for hardware extensions. On the other hand -- if a manager has so little trust in his own employees, he should probably just fire them (or himself).
It also restricts what data a sour employee can walk out of your company with.
It's basically impossible to do that. As long as you have any kind of electronic access to a node on the internet that you control (even telephone lines would suffice), you can transmit any data to it. And even if somebody actually "cuts the wire", you still have non-Pd-enabled devices like paper or/dev/brain at your disposal.
Just fine? You think an email client is lightweight?
You're the kind of person whose code would (A) go dog slow and (B) fall over given the mailing list archive for lkml with more than 1,000,000 messages in it, aren't you?
Yet, when such issues arise, it's typically the case that the program spends 99% of its CPU time in 1% of its LOCs. You then always have the option of rewriting the critical pieces in C and call that from your scripting environment.
A MUA is a primarily an interactive tool, and it should be highly configurable using scripts or plug-in code. You really don't want to write all of that in C, IMHO.
Which config files are you looking at? All the ones I've ever seen bury the important stuff somwhere in the middle of the file, usually segmented between two totally unrelated sections or even better, in a totally unrelated section. If there are any comments, they are usually cryptic and/or useless.
How does that differ from the average Windoze "preferences" dialog burying important options in 85 checkboxes and textfields, each one with a "cryptic" one-line explanation that can be understood only by reading the fine manual?
Right: The latter can't be easily created by scripts, nor easily managed using a version control system, nor easily augmented with self-written comments.
Re:No Post is Too Late: Send the Iraqis to Allah
on
4l-j4z333ra 0wn3d
·
· Score: 1
> Al-Jazeera deliberately distorts the news.
Freedom of the press is not about everybody telling the "objective truth", it's about everybody being allowed to tell whatever he wants (probably restricted by certain laws -- highly sensitive topic). The mere (presumed) fact that somebody "deliberately distorts the news" is no excuse for censorship.
That said, I don't think Al Jazeera distorts the news any more than, say, CNN does.
I did a course in my computer engineering degree last term called Formal Methods where half the course we spent learning the "Cleanroom" method of coding. To put it simply this method makes you specify functions through math and the prove via math that your code does do what it is intended to do.
That's nice, but it still leaves the problem of proving that the mathematical specifications correctly represent the (informally specified) requirements.
Which explains why nobody but a few Emacs geeks ever mess with.emacs. Oh, maybe a few people get handed a chunk of code and add it to the bottom of.emacs, but many of us would rather not do even that, as it will have fun! consequences when we upgrade..emacs is not the example to look towards for a user-friendly config system.
Hmm. What do you suggest? The problem seems to be that source files are machine-readable, but not (automatically) machine-editable. In Emacs you have the "options database" (a machine-edited file named something like "~/.emacs-options" that gets read in from somewhere in ~/.emacs). If you want more flexibility than offered by the options database, you'll have to start programming yourself. That's not much different to any other sufficiently complex piece of software.
The problem that relatively few people "mess with.emacs" appears to be related to the (IMHO unjustified) unpopularity of LISP. I still think that there are more people editing *ix configuration scripts than there are people writing VBScripts or having a systematic understanding of the mess that is the Windows registry, even though the latter is present on ~95% of all installed PCs:-).
The people who created ant would probably disagree.
Well, Java is just too baroque to be useful for its own Makefiles:-). Ant seems to require writing customized plug-ins in Java for all non-trivial tasks. Take Perl's MakeMaker for a different approach.
Shell scripts have their use in some places. Mixing configuration and functionality however is a stupid idea. You create all sorts of dependencies and basically is the primary reason UNIX sysadmins are so expensive.
That's a two-edged sword I guess. Unix would be long dead without it scripting capabilities. Most programming languages don't comprise distinct sub-languages for defining data structures and using them either, as doing so would introduce unnecessary overhead that can be easily avoided using a little bit of organization anyway.
? Too bloated, you say? Well, there you are:-). There is no binary encoding for XML data (as opposed to, say, ASN.1, which still gives you the possibility to validate your data against a specification). XML just isn't the right tool for such a job.
Re:The only once inside the GNOME-community
on
Has GNOME Become LAME?
·
· Score: 3, Interesting
Each and every application has it's own file, where it stores its configuration (which is not a problem) and it it's own syntax.
.profile,.bashrc, and.emacs, to name a few, contain source code. You'd have a hard time inventing an XML dialect for them, and doing it wouldn't save work in any way. You'd end up with basically unreadable files ten times as big as today's. XML is just too low-level for that kind of stuff, and its verbosity keeps getting in the way. These days people start integrating Javascript sections into their XML dialects...
I'm not sure you understand here. The.NET Framework is a collection of objects (similar to the Win32 API's) that all.NET managed code has access to.
I know.
Managed.NET code must be written with certain constraints, however.
C++ is not designed with these constraints in mind.
But, C# and VB.NET aren't the only languages out there. ActiveState has Python.NET and Perl.NET, there's COBOL.NET, Fortran.NET, Forth.NET, and even Pascal.NET (and many others).
According to this article, Perl.NET wraps the normal Perl interpreter (running as unmanaged code) and lets Perl code access the.NET runtime via special modules ("use perlNET") and special comments in the source code. I'm not saying that this is not useful, but it certainly doesn't make Perl a fully integrated.NET language like C# or VB.NET. (I haven't looked at the other languages you mentioned)
Jython, for example, has a better integration to the JVM (it's written in Java), and it does include a Python-to-Java bytecode compiler (though I don't know how well that one works).
But, managed code is a new addition to.NET that requires some adoptions in the programming languages.
The "some" depends. You should have a hard time integrating things like multiple inheritence, multiple dispatch, first-class functions or dynamic object systems (like Ruby's or CLOS's) into to the CLR as it stands today. AFAICS, you would either add these features yourself on top of the CLR (sacrificing a great deal of efficiency), or leave them out altogether, thereby making the language more similar to C# semantically.
I'm not stating that.NET isn't useful. I merely object to the claim that now that we have.NET, we can potentially use any programming language we want without significant problems.
you can write in C#.NET, VB.NET, etc. and still have access to the same objects
C#.NET and VB.NET (and managed C++) are more or less equivalent (the difference is only on the syntax level), and they were created to specifically meet the requirements of the CLR. This hardly proves anything.
If.NET really is that language-neutral, then one should ask why MS created 1 1/2 new languages specifically for the CLR instead of porting, say, ANSI C++ oder VB6 to it.
Slashdot Mirror
That's news to me. I know Haskell has things like "type classes" and a very smart type inferencer, but that doesn't make it dynamically typed, does it?
http://www.allianceonline.jp/productimgall/weblogi c.jpg
That's disgracing, but it doesn't invalidate my point (provided the "lack of respect" the OP mentioned referred to the French government's criticism of the war). The question is whether the French government shows a "lack of respect" for American soldiers in WWII by criticising US policy of 2003. Which I think it doesn't.
The notion that criticizing the US has anything to do with showing disrespect for what US soldiers did in WWII is devious.
Well, since most geeks don't build spacecrafts, and most space technicians don't design network protocols, we might as well work in parallel and do all at once :).
I doubt that any single person, let alone "Grandma", will ever manage "gigabytes and gigabytes" of highly structured data.
I'm an awfully untidy person (my home directory looks just as cluttered as my workroom), yet even I don't have any problems locating my project files or my photo collection.
If you really need to manage huge amounts of structured data, you may as well use an SQL database.
And performing search operations on such databases will only be fast if there is an index for the key(s) the search is based on. That is, at some point you'll have to anticipate the ways your data will eventually be used. Structuring data is a non-trivial task.
Btw, does anybody use the "indexing" feature of MS Office?
I wonder how many years it will take for Linux to play catchup to these kinds of features that I imagine will be commonplace by the time 2005 rolls around.
You can have database-like filesystems on Unix today. You can't on Windows.
And these features are in no way new; they have been "commonplace" in other OSes years ago.
Heck, I'm still holding my breath for a hardware accelerated X replacement, but the Linux zealots are too afraid of change for that to happen anytime soon...
WTF are you talking about? X has its problems, but it supports hardware acceleration.
I just downloaded the book from http://members.aol.com/Seb0013/uhh.pdf. acroread 4 on Linux (Debian testing) tells me that "there was an error opening this document (14)." acroread 5 says that "the file is damaged but is being repaired", and then keeps on "repairing" forever, using up all available CPU time. xpdf 1.00 reports
the MD5 checksum of the file is 60d0746053d204477d40e74c19a6aea2.msn.com: 2380 results
google.com: 62,300,000 results
"Linux":
msn.com: 603 results (3rd one being www.microsoft.com/serviceproviders/migration)
google.com: 56,600,000...
that's a long way to go for MS :)
Right: The latter can't be easily created by scripts, nor easily managed using a version control system, nor easily augmented with self-written comments.
> Al-Jazeera deliberately distorts the news. Freedom of the press is not about everybody telling the "objective truth", it's about everybody being allowed to tell whatever he wants (probably restricted by certain laws -- highly sensitive topic). The mere (presumed) fact that somebody "deliberately distorts the news" is no excuse for censorship. That said, I don't think Al Jazeera distorts the news any more than, say, CNN does.
The problem that relatively few people "mess with .emacs" appears to be related to the (IMHO unjustified) unpopularity of LISP. I still think that there are more people editing *ix configuration scripts than there are people writing VBScripts or having a systematic understanding of the mess that is the Windows registry, even though the latter is present on ~95% of all installed PCs :-).
I know.
According to this article, Perl.NET wraps the normal Perl interpreter (running as unmanaged code) and lets Perl code access the
Jython, for example, has a better integration to the JVM (it's written in Java), and it does include a Python-to-Java bytecode compiler (though I don't know how well that one works).
The "some" depends. You should have a hard time integrating things like multiple inheritence, multiple dispatch, first-class functions or dynamic object systems (like Ruby's or CLOS's) into to the CLR as it stands today. AFAICS, you would either add these features yourself on top of the CLR (sacrificing a great deal of efficiency), or leave them out altogether, thereby making the language more similar to C# semantically.
I'm not stating that
C#.NET and VB.NET (and managed C++) are more or less equivalent (the difference is only on the syntax level), and they were created to specifically meet the requirements of the CLR. This hardly proves anything.
If