Slashdot Mirror

Delegating administrative privileges can be controlled with extremely fine granularity using sudo, as this excellent series of articles point out.

Here is a relevant quote from the first article:
Once you have sudo configured correctly, you can change the root password and not give it to anyone. Nobody should need the root password if they have the correct sudo permissions, after all! Reducing the number of people who have the root password can help improve security.

Check out Advanced PHP Programming. Also O'Reilly's OnLAMP.com has a fairly good collection of tutorials.

Here's a nice, in depth interview at ONLamp with the core developer team from just last week. Covers a lot of ground, I found it very informative.

Quoting Matt Dillon, the project creator:

However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.

You can find more information if you actually visit the project homepage, or read a fairly recent ONLamp.com interview with the developers.

Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.

Speaking about Perl and Assembly, it is important to mention that there are modern object-oriented assembly languages with asynchronous I/O, events, threads, multiple inheritance, garbage collection, built-in Unicode support, etc. See: Parrot Assembly, and IMCC:

"IMC stands for Intermediate Code; IMCC stands for Intermediate Code Compiler. You will also see the term PIR which is for Parrot Intermediate Representation and means the same as IMC, but for some each Parrot developer has his favorite term. PIR was the original term, where IMC seems to be the vernacular. It is an intermediate language that compiles either directly to Parrot Byte code, or translates to Parrot Assembly language. It is the preferred target language for compilers for the Parrot Virtual Machine. PIR is halfway between a High Level Language (HLL) and Parrot Assembly (PASM)."

"PASM is an assembly language, raw and low-level. PASM does exactly what you say, and each PASM instruction represents a single VM opcode. Assembly language can be tough to debug, simply due to the amount of instructions that a high-level compiler generates for a given construct. Assembly language typically has no concept of basic blocks, namespaces, variable tracking, etc. You must track your register usage and take care of saving/restoring values in cases where you run out of registers. This is called spilling.

"IMC is medium level and a bit more friendly to write or debug. IMCC also has a builtin register allocator and spiller. IMC has the concept of a "subroutine" unit, complete with local variables and high-level sub call syntax. IMCC also allows unlimited symbolic registers. It will take care of assigning the appropriate register to your variables and will usually find the most efficient mapping so as to use as few registers as possible for a given piece of code. If you use more registers than are currently available, IMCC will generate instructions to save/restore (spill) the registers for you. This is a significant piece of every compiler.

"While it is possible to write more efficient code by hand directly in PASM, it is rare. IMC is still very close to PASM as far as granularity. It is also common for IMCC to generate instructions that use less registers than handwritten PASM. This is good for cache performance."

For a good introduction to Parrot, read Parrot: Some Assembly Required by Simon Cozens. There is a great article (also on ONLamp.com) Building a Parrot Compiler by Dan Sugalski (I have no idea why it wasn't posted on the Slashdot front page).

(By the way, for those who read off-line, here is a printable version of the linked Why Learning Assembly Language Is Still a Good Idea article in one piece.)

Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.

Speaking about Perl and Assembly, it is important to mention that there are modern object-oriented assembly languages with asynchronous I/O, events, threads, multiple inheritance, garbage collection, built-in Unicode support, etc. See: Parrot Assembly, and IMCC:

"IMC stands for Intermediate Code; IMCC stands for Intermediate Code Compiler. You will also see the term PIR which is for Parrot Intermediate Representation and means the same as IMC, but for some each Parrot developer has his favorite term. PIR was the original term, where IMC seems to be the vernacular. It is an intermediate language that compiles either directly to Parrot Byte code, or translates to Parrot Assembly language. It is the preferred target language for compilers for the Parrot Virtual Machine. PIR is halfway between a High Level Language (HLL) and Parrot Assembly (PASM)."

"PASM is an assembly language, raw and low-level. PASM does exactly what you say, and each PASM instruction represents a single VM opcode. Assembly language can be tough to debug, simply due to the amount of instructions that a high-level compiler generates for a given construct. Assembly language typically has no concept of basic blocks, namespaces, variable tracking, etc. You must track your register usage and take care of saving/restoring values in cases where you run out of registers. This is called spilling.

"IMC is medium level and a bit more friendly to write or debug. IMCC also has a builtin register allocator and spiller. IMC has the concept of a "subroutine" unit, complete with local variables and high-level sub call syntax. IMCC also allows unlimited symbolic registers. It will take care of assigning the appropriate register to your variables and will usually find the most efficient mapping so as to use as few registers as possible for a given piece of code. If you use more registers than are currently available, IMCC will generate instructions to save/restore (spill) the registers for you. This is a significant piece of every compiler.

"While it is possible to write more efficient code by hand directly in PASM, it is rare. IMC is still very close to PASM as far as granularity. It is also common for IMCC to generate instructions that use less registers than handwritten PASM. This is good for cache performance."

For a good introduction to Parrot, read Parrot: Some Assembly Required by Simon Cozens. There is a great article (also on ONLamp.com) Building a Parrot Compiler by Dan Sugalski (I have no idea why it wasn't posted on the Slashdot front page).

(By the way, for those who read off-line, here is a printable version of the linked Why Learning Assembly Language Is Still a Good Idea article in one piece.)

The firewall can look at packets and determine which operating system they came from by looking at those differences. ... The integration into the firewall allows the administrator to filter or redirect connections based on the operating system of the client. ... Find email worms annoying? Block mail that came directly from Windows machines instead of going through a UNIX mail server.

$ opiepasswd -c
Adding dlavigne6:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Secret pass phrases must be between 10 and 127 characters long.
Enter new secret pass phrase:
Again new secret pass phrase:

ID dlavigne6 OTP key is 499 dh0391
CHUG ROSA HIRE MALT DEBT EBEN

$ opiekey 498 dh0391
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
MASK BALM COL HER RIFT TERM

$ opiekey -n 10 497 dh0391

Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
488: COIN LO DOG GOLF ACTA FULL
489: SOD STUN SINK DRAW LAWN TILT
490: MALT STAY MASH CAR DEBT WAST
491: HOWE DRY WALL TOO BUDD SWIM
492: ROOT SPY BOND JEST HAIL SCAR
493: MEAN ADD NEON CAIN LION LAUD
494: LYLE HOLD HIGH HOME ITEM MEL
495: WICK BALI MAY EGO INK TOOK
496: RENT ARM WARN ARC LICE DOME
497: LEAD JAG MUCH MADE NONE WRIT

login: dlavigne6
otp-md5 498 dh0391 ext
Password: (here I pressed enter)
otp-md5 498 dh0391 ext
Password [echo on]: mask balm col her rift term

• web development: Not only Zope and Plone, there's a lot of interesting development going on with Twisted... and, well, Twisted is not only about the web, it is about networking in general;
• .NET / Java development in general: Python in Java exists already... Java gaining more and more popularity? No problem, Python is already there. .NET/Mono taking the market away from Java? The industry will perhaps support more and more .NET techniques - with IronPython (featured recently on /.), Python is already there. No problem;
• some people might wonder if you really need that stinkin' .NET/Java stuff at all - Python is already very portable, but that's not everything - it already supports a wide range of MacOS/Unix/win32-specific functionalities.
• anything else makes you wonder, if Python is a good choice at all? What about realtime applications, like a VOIP phone (GUI included, win32/unix compatible) in Python? Do you read "interpreted" as "slow", do you wonder if Python is good enough to be useful in CPU-demanding programs like games? Anything else against it? Perhaps you're worried about Python's extensibility?
• if software telephony sucks for you, perhaps you should try a real mobile phone

Nonsense. The P is for Perl, Python or PHP.

http://www.onlamp.com/pub/a/onlamp/2001/01/25/lamp .html

When I first saw the headline about "painlessly updating", I thought this might be a great article about some new innovative way to update. Its not really anything new or interesting though, the whole article is basically saying: "cd /usr/src && make world && make kernel && mergemaster will update you system"

Not wanting to sound rude, but no shit sherlock! Yes, this is a painless way to update your system. It is also the way to update your system, as is very well spelled out in the excellent FreeBSD Handbook so I'm not sure why it warrants an article....

Maybe its just me but I think an article about portupgrade or something would have been more useful.

Well, if you want a innovative language (rather than a pragmatic one), Haskell should definitely not be left out. Granted, it may be a little hard to use if you just want to write real-life programs (quite a lot of computer-science stuff are involved just for mutable state), but its interestingness beats OCAML and even Lisp if you are getting tired of 20 slightly different imperative languages. The language is also well supported in the free software community.

Haskell is very interesting indeed. And there are already plans to write a Haskell compiler targetting Parrot. (The relative interestingness is a very subjective matter, though.) There is already a Scheme compiler written by Juergen Boemmels and Jeffrey Goff (version 0.0.11 is "Functioning, as far as implemented. Lists and functions are working but many functions are missing implementation.") so Lisp, OCAML and Haskell compiler writers will have some interesting prior art to base their compilers on. I really look forward to having as many languages targetting Parrot as possible. The very recent ONLamp article, Building a Parrot Compiler (It's not just for Perl 6 anymore) by Dan Sugalski, is a great start for anyone planning to write a Parrot-targetting compiler. That's pretty amazing that three years ago Parrot was only an April Fool's joke...

Of course, I'm not disparaging Larry's work here. Perl is a good and pragmatic language, and I'm glad to find it getting rid of the historical ugly parts..

As a sidenote I might add that Perl 6 will support the functional paradigm. It is just not the only paradigm it will support.

Yep -- but how would that have helped here? The thing wasn't a virus spread by email -- the first thing to see the packets would have been the firewall, which is what keeled over.

Also it leads to the conclusion that user-assisted updates are useless and only automatic updates can effectively patch fast enough to block worms of this sort.

One other thing that might help is something like OpenBSD's systrace. Basically, it limits what syscalls you allow programs to have. What about something like a firewall that said, "Whoa, suddenly your firewall is calling bind() 80 times more than usual -- better check it out"? (I realize that's kind of a crappy, faux-geeky example, but you can see what I'm getting at, and anyway surely this could be made much more intelligible to regular users.)

This is one of the most depressing stories about the state of the Internet that I've read in a while.

Amen.

Hmmm, it seems that another approach might also provide these desirable side benefits but also work to secure the Internet as a whole, and not have to use "Trusted" architectures. Although, there are new controversies from the following approach, in short, from my journal: "an emerging Internet security company, Symbiot is taking an entirely new, albeit controversial approach to Internet defense and cyberwarfare that should appeal to cyberpunks everywhere. Rather than the traditional passive response that has been used by sysadmins and CTO's worldwide, Symbiot is taking a more "active" defense approach by implementing a common subscription based access to a "threat database" that will allow participating networks to determine the degree of threat and respond democratically (by using the shared resources of other participating networks) and proportionally to the attack by allowing for a graduated response to cyber attacks. The potential of an asymmetrical response to a threat is also not out of the question.... Links for additional information are here and here."

Stackless Python?

Thanks for the link. Unfortunately from reading the article and according to Stackless Reincarnate:-

Stackless was a controversial modification to Python, separating its execution stack from the C execution stack, the C-stack.

Stackless Python?

Thanks for the link. Unfortunately from reading the article and according to Stackless Reincarnate:-

Stackless was a controversial modification to Python, separating its execution stack from the C execution stack, the C-stack.

Stackless Python?

When you start feeling that PHP doesn't have the muscle to do what needs to be done, you might want to check out PSP (Python Server Pages) which is a standard feature of new mod_python, and very much like PHP, with the exception of using a more sophisticated language for scripting.

An article with example code can be read here

Great. The one thing I'm dying for is a video game about how the Lead Programmer grew up in a small town in Michigan after the coal mine dried up and left his family with a hefty mortgage and a distant, alcoholic father.

Seriously, you see some pretty innovative games in the shareware scene. Also, the obligatory, marginally helpful link.

Here is an interview that Andy Oram did with Symbiot (collectively, apparently). It includes much more information regarding their product. Worth a read.

You mean, like FreeBSD's portupgrade?

(Yeah yeah, portupgrade layers on top of the existing FreeBSD package system but still, this isn't *that* mind-blowing.)

If you want to talk about the power of ruby, I can think of a lot more cool things. Like, how you can add aspect-oriented programming without modifying Ruby or using any pre-compiling, or how you can write a profiler for Ruby programs, in Ruby itself, without any external hooks, in under 200 lines. Or how you define the "+" operator by using "def +(x)" instead of "def __add__(self, x)". Etc. Etc.

The New Breed of Version Control Systems

The DLLs get large because Microsoft dictates that they must remain backwards compatible, so that an application coded for dllhell.dll version 1 will still work for dllhell.dll version 6 without recompiling. This is one thing Windows does have that Linux doesn't. [Emphasis added.]

I'm going to have to respectfully disagree on this one. The typical approach here is to use a packaging system (like rpm, dpkg, BSD ports, or even OpenPKG). These packaging systems manage dependencies (including old versions of shared libraries).

For example, on some RPM-based distros, KDE 3.1.something required an older version of OpenSSL, so the new and old shared libraries were included:

$ rpm -qa | grep -i openssl | sort
...
openssl096-0.9.6-something
openssl096b-0.9.6b-something
openssl-0.9.7a-something
...

Instead of including all of the backward-compatible symbols, etc. in one DLL, it's split up among several different shared objects. That way, only the required objects are included instead of the kitchen sink approach.

$ rpm -ql openssl096 openssl096b openssl | grep /lib/
/usr/lib/libcrypto.so.0.9.6
/usr/lib/libssl.so.0.9.6
/lib/libcrypto.so.0.9.6b
/lib/libssl.so.0.9.6b
/lib/libcrypto.so.0.9.7a
/lib/libssl.so.0.9.7a

However, you are correct that the packager does need to take more care in setting up the dependences, since one can't just assume that the necessary libraries (old or new) are installed on the system. One could argue that with cheap disk space, why not include everything? Purists would tend to site clutter, security problems, the tendency for increasing complexity to result in erratic behavior, and other inconveniences as reasons to avoid this approach, however.

"Learn Scheme. Download "DrScheme" and use it while you go through "How to Design Programs," a free online book for learning to program with Scheme. After that, go to half.com and buy "The Structure and Interpretation of Computer Programs" for around $10 (it'll be an old edition, but that's alright) and read through it, doing all the exercises it suggests.

If you do that, you'll not only know how to program, but you'll be a better programmer than probably 97% of the people on this board. Which doesn't say much, to be sure, but you'll find that the solid basis in programming that you've developed will allow you to learn any language you want easily. And you'll be able to program well in those languages."

Dr. Scheme
How to Design Programs (Uses Scheme to teach programming)
The Structure and Interpretation of Computer Programs (also uses Scheme to teach programming)

For those who're interested in Ruby, I've found a tutorial on that as well.

= 9J =

Because its a server application the program doesn't have to be installed on different machines (except the web browser), which makes it easier to install. Programming some stuff in a web interface is tough, but not too too bad.

I actually did the demo on an ibook (ran the database/webserver, client browser on one machine. . used fink to install MySql and a php package from entropy.net. So easy to install I was amazed. although if I deploy I'll compile myself to set the options exactly as I want.

Comments, Opinions, Ideas, Links?

Recipe 7.4: Serving a Portion of Your Site via SSL from O'Reilly's Apache Cookbook ?

JP

Well worth the read

1. Remember the battles between network protocols, and how TCP/IP inexorably took over the whole domain until "network = TCP/IP" became a self-evident truth.

   The same is IMO inevitable with Linux because it has solved the main issue of how to provide the necessary services on any platform in a non-partisan manner. ...

I do remember the old protocols as I ran a test lab with a dozen servers -- mostly using different propriatory protocols.

Linux isn't based on propriatory interfaces, so making a "Linux clone" work transparantly with Linux binaries -- let alone source code -- is not only possible, it has been done already -- even for the PPC!

FreeBSD has for a long time been THE STUFF for speed, but that's not quite true longer since the release of Linux 2.6.

Ports offer a great advantage if you want to build stuff with your own options, but it requires time, bandwidth and some knowledge of what you are doing. The speed difference will probably not be worth it but atleast you don't have to use all those toolkits you don't like anyway.

Philosophy? Definitly, now we are talking. If you are a developer the BSD License let you enjoy the greatness of having all the source code at your hands without having to release your own works source just because you found a nice idea or borrowed some code.

But imho the great thing with all the BSDs are documentation. Sure you have manpages in Linux, sure there are howtos, and even install guides. But with the hundreds of Linux distributions and different places and names of files and modified content of them it doesn't come close to the documentation you have in any of OpenBSD, NetBSD or FreeBSD.

FreeBSD handbook
NetBSD documentation
OpenBSD F.A.Q.
OpenBSD stable documentation
O'reillys BSD articles

the o'reilly network security articles are another great resource for the advanced system administrator.

plus, they're free..

There's a good article by John Todd at o'Reilly here.

Here's a Guide to Asterisk.

There's also a Wiki

Although I might have missed your point here, I believe what you are describing is similar to FreeBSD jails :)

A five second Google search turns up a lot of information on this topic.

Here's a solution for FreeBSD. A little time spent searching and you can probably find a similar solution for RH.

FreeBSD has sandbox infrastructure called "jail". The idea is to sandbox all services so that an exploits can't escalate itself into root.

Jail chroots an environment and sets certain restrictions on processes which are forked from within. For example, a jailed process cannot affect processes outside of the jail, utilize certain system calls, or inflict any damage on the main computer

Systrace takes a different approach, i.e.

With systrace, a system administrator can say which system calls can be made by which programs and how those calls can be made. Proper use of systrace can greatly reduce the risks inherent in running poorly-written or exploitable programs. systrace policies can confine users in a manner completely independent of Unix permissions. You can even define the errors that the system calls return when access is denied, to allow programs to fail in a more proper manner. (source)

I just started getting into open source database development as a hobby. While my work mate recommended postgreSQL, I decided to go with mySQL.

Call me a lemming, but the huge amount of combined Linux-Apache-PHP-mySQL (LAMP)documentation is what convinced me to go with mySQL. Once I become more comfortable with this setup, I'll give postgreSQL a try. But for a newbie, mySQL seems friendlier at the moment, if only because of the wide amount of help available.

Well, in this interview, Emmanuel Dreyfus gives some reasons why he did it. It's your call whether or not they're good reasons!

> Why not use MOL (Mac On Linux)?

There are some anwsers about this here

"Well, MoL is much like the PowerPC equivalent of i386 software such as VMWare or Plex86: these are virtual machines inside which you run the whole foreign OS, kernel included. It's like another machine inside your machine.

Binary compatibility makes it possible to run the foreign OS binaries on top of the NetBSD kernel. It is possible to mix binaries from NetBSD and the emulated OSes: they are able to communicate through pipes or sockets, you see them in the process list with ps, a foreign OS binary is able to launch a native process, and so on. Binary compatibility enable me to run an anti-virus software build for Linux as a filter in my NetBSD mail server, for instance. "

FreeBSD jails?

Nice response to the Forbes nonsense at Oreilly Weblogs

Forbes Magazine Doesn't Understand Capitalism by William Grosso

Nice summary...

Leaked? Dark side? Happy proles singing the "Internationale" ? Can you count the ways in which that paragraph is an offense to journalism?

Don't know if this was posted yet:

http://www.onlamp.com/pub/wlg/3880

-Dan

a)
1. Find name of package you need
2. Find the package
3. Download package you need
4. Build package you need
5. Find and download any and all dependencies (the real time consumption)
6. make install

The order is more like this.
a) to build from source
1. Find name of package (either via `cd /usr/ports && make search name=packagename`) or though browsing the online ports collection.
2. cd to the port dir
3. `make install clean`

b) to get pre-compiled source
1. Find name of package (either via `cd /usr/ports && make search name=packagename`) or though browsing the online ports collection.
2. `pkg_add -rv packagename`

For example I can install kde in either 5-10 mins or 2-3 hours. The FreeBSD has many more options and is very powerful. A look at the ports man page and all of the pkg_* tool's man pages would revel alot of extra usage.

Two useful articles from onlamp:
Ports Tricks
Cleaning and Customizing Your Ports

a)
1. Find name of package you need
2. Find the package
3. Download package you need
4. Build package you need
5. Find and download any and all dependencies (the real time consumption)
6. make install

The order is more like this.
a) to build from source
1. Find name of package (either via `cd /usr/ports && make search name=packagename`) or though browsing the online ports collection.
2. cd to the port dir
3. `make install clean`

b) to get pre-compiled source
1. Find name of package (either via `cd /usr/ports && make search name=packagename`) or though browsing the online ports collection.
2. `pkg_add -rv packagename`

For example I can install kde in either 5-10 mins or 2-3 hours. The FreeBSD has many more options and is very powerful. A look at the ports man page and all of the pkg_* tool's man pages would revel alot of extra usage.

Two useful articles from onlamp:
Ports Tricks
Cleaning and Customizing Your Ports

if the article clearly states that *c* is a prerequisite and is about gcc compiler internals on a very specific hardware platform the article is clearly catering for the technical specialist knowlegeable/or interested about such topics. why shouldnt it be on the front page. Since when has the front page been *slashdot for idiots* ?

if you cannot understand *c* or take the time to read and understand the suggested references then do not be surprised the article is unaccessable. Typical young /. whipper snapper wanting everything NOW ... :)

Dare you *not to do your homework* and post statements like this on the openbsd or gcc usenet forums ... hung drawn and quartered before you could even spell slashdot.

RTFM, RTFTB, man gcc(1), read the manual, already faq ...

Maybe a better suggestion maybe to post a question in the discussion asking for help or for someone to summarize the interesting points. Must use slashdot powers for good, not evil :)

Yes, splittling it up would be an excellent idea, which is one of the reasons why I find ONLamp.com to be fairly helpful -- each article is on a discrete topic.

W.r.t. sendmail vs. qmail vs. postfix: I certainly wasn't trying to start a mailer war.

Sample chapters of the book can be found here and here. I read this first one (the one on TCP/IP) and found that it was an excellent introducation to it. The other is on "secure programming techniques." Gotta read that.

At the risk of bringing this back on topic...

Does Mr. Lucas address OpenBSD's compat_linux?

http://www.openbsd.org/faq/faq9.html

He does in the book's predecessor "Absolute (Free)BSD" and has a rocking article on compat_linux "the hard way" at OnLamp

MD

...and whilst that was a nice informative article, it was also noticeably linux specific (of course, you couldn't be trolling - not with a closing line like that).
This being the BSD area of /., I think a few BSD targetted articles on configuring WAPs
might be more apt.

That said, this WiFiBSD thing looks like a nice little development. Could well come in handy.

Read this before returning the book: What's New in Python 2.3? (From the author of the book)

Alex Martelli has written an article that talks about the changes from Python 2.2 to 2.3.

David, thanks for making your book available on-line. I'll be sure to look for a 'dead tree' version.

O'Reilly: How much of the technical advantage stems from the original BSD code or from the newer developments coming from the FreeBSD team?

Bostic: Both. Certainly some of it is the original BSD code. Both the network stack and the filesystem work came from the original BSD code. Doing a good network stack is a very difficult project -- the BSD stack has at least 15 years of development in it now, and lots of very bright people spending serious research time on making it work. Linux and Microsoft both started from scratch, and it showed.

That said, FreeBSD has done a much better job of leveraging the community for quality than Linux has. Note the phrase "for quality" -- that's what makes that sentence correct. Linux is still very much directed by a small core, while FreeBSD has pushed the core developer group out into a larger set of people. One of the things I admire most about Jordan Hubbard is the job he's done in herding the cats and pushing FreeBSD's quality forward. He's done a better job of distributed management than we ever did at UC Berkeley (although, in our defense, he has better tools and infrastructure than we ever had at UC Berkeley, for example, the Web and high-speed networking).