Re: How do I write directly to a memory address?

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message 
news:4d6f2fcb$0$14547$882e7ee2@usenet-news.net...
> On 3/2/2011 10:01 PM, Randy Brukardt wrote:
>> Relational databases have their uses, but they're wildly
>> overused for things that are only weakly related to transactional data. 
>> As
>> Dmitry said, there are better approaches to persistence.
>
> Are there? Relational databases have the feature of *working*. They are
> among the most widely used programs, especially in the finance industry
> (so you are in fact benefiting from the money Wall Street spends on
> them)

Yup -- if all you have is a hammer, everything looks like a nail. :-)

>... , they scale well from tiny table sizes to enormous ones,

Which is the best (and virtually only) reason for using them, IMHO. If you 
don't need wild scaling, you probably don't need a database. And that is 
especially true on the "tiny table" side.

>  and using them is a well-understood art.

See my first comment.

> If you're working for a company of
> reasonable size, it is most likely already using databases, so you can
> piggyback on the services the company is already using for maintenance,
> support and backup.

If a technology needs much maintainence or support, it is already a lost 
cause. See my 98% note above. People aren't flocking to buy iPhones and 
iPads instead of Windows netbooks because they could use the same mechanism 
for maintenance and support! They're buying them because they don't need 
(much) maintenance and support.

A well-designed persistence mechanism is the same thing; it just works as 
part of your program and considerations about *how* it works are irrelevant. 
It's the same dynamic that has led to the heavy use of containers rather 
than roll-your-own data structures in new programs. Interfacing to a 
database is hard for most programming languages, with a significant 
disconnect between the data types in the program and in the database. Good 
persistence mechanisms don't suffer from that.

> Do those "better" methods buy you all that?

Doing things the same old, "safe" ways also buy you all of the problems of 
interfacing, the need for experienced database administrators, etc. Does 
those costs buy enough? Who knows.

> > Nor can any URL cause the launching of a shell, because it doesn't have
> > the capability to run another program
>
> Normal web servers offer the ability to launch scripts based on URL
> patterns (CGI, remember?), so this means you have failed to implement
> a standard bit of functionality.

Given that I don't need or want that functionality, all I'm doing is 
following the important principle of least priviledge (admittedly a bit 
extremely). The advice is always don't run services you don't need, don't 
give permissions to users that don't need them, etc. I'm doing the same 
here, don't provide a way to launch programs because I don't need it.

Note that my web server (as opposed to the AWS package discussed here by 
others, please don't be confused by the similar names) was never intended to 
do anything beyond run the web sites I'm responsible for. Someone else could 
take the source code and tailor it for another site, but the entire idea was 
to make the security as strong as possible by requiring anything that the 
web site could respond to be compiled-in Ada code. I'm planning to port the 
code to Linux in the near future, which will eliminate it's primary weak 
link (running on top of Windows).

I'm well aware that other people have different requirements. There is no 
one-size-fits-all answer to security or functionality.

                                       Randy.