Since you want to run serveral services on this machine I'd suggest using FreeBSD and using jails to have every kind of service (mail / web / db / dns.. whatever) running in its own environment. This makes things much safer if one of the services is compromised, as it won't affect the rest that much. You can even give the jails' root passwords to co-admins: i.e. everyone has to care about one single service.
That's only because people have to redownload it as they keep trashing their windows systems with Kazaa and all the spyware and malware it brings despite all the junk that people will actually download.
We're currently developing a webbased helpdesk/trouble ticket system for our company.
In order to make it easy for the users to log in (i.e. using their regular usernames/passwords), we used the smbauth module for apache which authenticates the users at the NT PDC.
Works very nice.
To avoid clear text traffic, we use https, of course.
The author of the article suggests that companies like verisign should sell certificates to users. I think that'd be wrong and no doubt quite expensive, destroying the foundation of email itself. Also, dropping the current protocols is not necessary.
But verification is a nice idea that must not to be abandoned.
I propose that ISPs themselves do the verification (they should do this anyway to be sure their bills get paid).
Usually when you sign up with an ISP you get an email address. Now, you just get a verification signature, too.
The smtp server of your ISP would check your signature and ensure that all headers are correct.
The sender verification at the target would be a simple request to the verification server of the ISP that's hosting the sender. (These servers should have some sort of signature like SSL)
Checks could include the message id or a checksum of the headers generated and stored by the smtp server. (Thus, still keeping privacy.)
I think this approach is both logical and simple (and cheap). And it could be implemented on top of the current system.
In the beginning it won't stop spam being sent through open/exploited relays. But mail from untrusted sources could be easily filtered out. Later it could be blocked altogether if verified emailing would be widely adopted.
First of all, it was a joke. You know: It's funny, laugh.
Additionally, coming from a country with a very outstanding beer culture (that can be read as culture of brewing as well as a beer minded/dumbed culture) I allow myself to have a strong opinion about our favourite liquid.
Last not least, I appreciate your comment having learned a lot from it about recent American brewery history. As I get the chance I will try your beer again.
This is a very nice idea. But for more usability the record should include the location (country and continent) of each mirror, so your favourite download manager can try the nearest mirrors first.
Another question is how quick such lists would be replicated/cached by your ISP's DNS server...
This digital library is a very good idea. For technical reference it's way better to have a online version of the book than having a paper book besides your keyboard (makes my neck hurt very quickly).
Because of that I usually even search the net for some scanned version of books I have the paper version of.
Reading a whole book from beginning to end is much more comfortable with paper versions, though. I also woudln't want to read (for example) philosophical or lyrical text online: these types of books just need paper versions, they're not the same otherwise.
Despite that, nothing beats the beauty of a well filled (real world) book shelf.
> But that's no use in this case, because you want unregistered MAC addresses to be able to communicate with the registration server.
Just use VLANs. I.E. put the reg server and all the unregistered MACs in a seperate VLAN. Servers as well as internet routers should then be in another VLAN to which only registered MACs have access.
You could even further fine grain these setup (i.e. seperate VLANs for different departments).
By the way, the nice switches from Enterasys support even Radius authentification! That's even nicer.
I agree with you. I don't use another operating system because it's the same as the old one.
If I'm not using (or forced to use) Windoze, I'm all for the GNUstep UI: very clean and well thought; great environment (drag'n'drop, services, etc)...
And of course, there is Apple's OS X, which gladly still kept some of the nice NeXT stuff.
Even if I could get songs for free, I'd rather pay the artists: because I'd pay the *artists*, not some pointy haired assholes. (Additionally I'd pay the IT people that do the hosting/webshop programming, etc - another pro!)
Cocoa is heavily based on the OpenStep API. They changed a lot of things, though; and added lots of new stuff.
The entire system (file system hierarchy, having a mach kernel, bsd userland, dock, services, etc) is pretty much similar to OPENSTEP/NEXTSTEP.
The only thing really missing is the cross platform ability. But here, GNUstep comes into the game, again. It's just lovely to see GNUstep apps run on UNIX and Win32 (although Win32 gui support is alpha stage currently), as well as OS X.
One nice thing about GNUstep [http://www.gnustep.org] is its scope of localization possibilities.
Basically (i.e. following the OpenStep standard) the system has localization files which contain formats for dates, monetary strings, whether and when to use dots or commas (3,000.50 would be 3.000,50 in German), etc.
Unicode usage is built-in and was supported since the early days of the project. (Klingon characters do display very well.)
Applications can have localized strings, of course. It is possible to automatically create the [Lanaguage].lprof/Localizable.strings files from the source, only adding strings which haven't been translated, marking obsolete ones, etc.
Additionally it is easily possible to have hand crafted/adjusted user interfaces for different languages. Either using Gorm (the Interface Builder) files for every language, or using Renaissance (the xml based user interface format) which can both: lookup localized strings and have custom interface files for specific languages.
I guess that possibly outstanding issues (read direction and text layout maybe) will be addressed, too.
Of course, GNUstep (and to some point Apple's Cocoa) has a lot of other great features. Just check it out;-)
Just to clarify: 'OpenStep' was the API. 'OPENSTEP' was the implementation (aka the OS). OPENSTEP is a UNIX the same as NeXTStep was a UNIX and Mac OS X is a UNIX or Solaris is a UNIX...
Pith != tabs... yet
on
Tabs for Safari
·
· Score: 5, Informative
While it's true that Pith is a nice tool, it is not exactly comparable to Mozilla's tabs. Some of Pith's shortcomings may exist due to its beta stage, but I wonder whether it's possible for Pith to fully achieve its goal. One major downside is the performance hit caused by the heavy safari window showing/hiding.
Slashdot Mirror
When you give your soul to the devil, you don't get it back, do you?
Since you want to run serveral services on this machine I'd suggest using FreeBSD and using jails to have every kind of service (mail / web / db / dns.. whatever) running in its own environment.
This makes things much safer if one of the services is compromised, as it won't affect the rest that much.
You can even give the jails' root passwords to co-admins: i.e. everyone has to care about one single service.
Now they exposed themselves!
I guess the core must be in one of those tech buildings that we mere mortals call pyramids.
Go get 'em.
Damn Neighbours.... making their own window managers now....
That's only because people have to redownload it as they keep trashing their windows systems with Kazaa and all the spyware and malware it brings despite all the junk that people will actually download.
Happy fortnighty format C: everyone.
p.s.: Ad-Aware helps, too.
...but the only power that's going over my network is the *p0wer of pr0n*.
We're currently developing a webbased helpdesk/trouble ticket system for our company.
In order to make it easy for the users to log in (i.e. using their regular usernames/passwords), we used the smbauth module for apache which authenticates the users at the NT PDC.
Works very nice.
To avoid clear text traffic, we use https, of course.
The author of the article suggests that companies like verisign should sell certificates to users. I think that'd be wrong and no doubt quite expensive, destroying the foundation of email itself. Also, dropping the current protocols is not necessary.
But verification is a nice idea that must not to be abandoned.
I propose that ISPs themselves do the verification (they should do this anyway to be sure their bills get paid).
Usually when you sign up with an ISP you get an email address. Now, you just get a verification signature, too.
The smtp server of your ISP would check your signature and ensure that all headers are correct.
The sender verification at the target would be a simple request to the verification server of the ISP that's hosting the sender. (These servers should have some sort of signature like SSL)
Checks could include the message id or a checksum of the headers generated and stored by the smtp server. (Thus, still keeping privacy.)
I think this approach is both logical and simple (and cheap). And it could be implemented on top of the current system.
In the beginning it won't stop spam being sent through open/exploited relays. But mail from untrusted sources could be easily filtered out. Later it could be blocked altogether if verified emailing would be widely adopted.
First of all, it was a joke. You know: It's funny, laugh.
Additionally, coming from a country with a very outstanding beer culture (that can be read as culture of brewing as well as a beer minded/dumbed culture) I allow myself to have a strong opinion about our favourite liquid.
Last not least, I appreciate your comment having learned a lot from it about recent American brewery history. As I get the chance I will try your beer again.
you call that stuff "beer"?
FreeBSD 5.x has fs snapshot capabilities. See http://www.freebsd.org/releases/5.0R/relnotes-i386 .html#AEN1150 for more details.
This is a very nice idea.
But for more usability the record should include the location (country and continent) of each mirror, so your favourite download manager can try the nearest mirrors first.
Another question is how quick such lists would be replicated/cached by your ISP's DNS server...
The crystal pictures with the light blue background colour make nice background pictures for OS X as they play nicely with Aqua's blue.
This digital library is a very good idea. For technical reference it's way better to have a online version of the book than having a paper book besides your keyboard (makes my neck hurt very quickly).
Because of that I usually even search the net for some scanned version of books I have the paper version of.
Reading a whole book from beginning to end is much more comfortable with paper versions, though. I also woudln't want to read (for example) philosophical or lyrical text online: these types of books just need paper versions, they're not the same otherwise.
Despite that, nothing beats the beauty of a well filled (real world) book shelf.
Is she buying a lot of well advertised products lately?
which would fit into one two categories: 1. solution for already solved problem, 2. killer feature.
> But that's no use in this case, because you want unregistered MAC addresses to be able to communicate with the registration server.
Just use VLANs. I.E. put the reg server and all the unregistered MACs in a seperate VLAN. Servers as well as internet routers should then be in another VLAN to which only registered MACs have access.
You could even further fine grain these setup (i.e. seperate VLANs for different departments).
By the way, the nice switches from Enterasys support even Radius authentification! That's even nicer.
I can only encourage you to do so.
But be aware that the gui part of GNUstep still has its rough edges.
Be sure to subscribe to the discuss-gnustep mailing list and post your thoughts/problems/etc.
Now it's coloured...
I agree with you. I don't use another operating system because it's the same as the old one.
If I'm not using (or forced to use) Windoze, I'm all for the GNUstep UI: very clean and well thought; great environment (drag'n'drop, services, etc)...
And of course, there is Apple's OS X, which gladly still kept some of the nice NeXT stuff.
No, I don't think so.
Even if I could get songs for free, I'd rather pay the artists: because I'd pay the *artists*, not some pointy haired assholes. (Additionally I'd pay the IT people that do the hosting/webshop programming, etc - another pro!)
Cocoa is heavily based on the OpenStep API. They changed a lot of things, though; and added lots of new stuff.
The entire system (file system hierarchy, having a mach kernel, bsd userland, dock, services, etc) is pretty much similar to OPENSTEP/NEXTSTEP.
The only thing really missing is the cross platform ability. But here, GNUstep comes into the game, again. It's just lovely to see GNUstep apps run on UNIX and Win32 (although Win32 gui support is alpha stage currently), as well as OS X.
One nice thing about GNUstep [http://www.gnustep.org] is its scope of localization possibilities.
;-)
Basically (i.e. following the OpenStep standard) the system has localization files which contain formats for dates, monetary strings, whether and when to use dots or commas (3,000.50 would be 3.000,50 in German), etc.
Unicode usage is built-in and was supported since the early days of the project. (Klingon characters do display very well.)
Applications can have localized strings, of course. It is possible to automatically create the [Lanaguage].lprof/Localizable.strings files from the source, only adding strings which haven't been translated, marking obsolete ones, etc.
Additionally it is easily possible to have hand crafted/adjusted user interfaces for different languages. Either using Gorm (the Interface Builder) files for every language, or using Renaissance (the xml based user interface format) which can both: lookup localized strings and have custom interface files for specific languages.
I guess that possibly outstanding issues (read direction and text layout maybe) will be addressed, too.
Of course, GNUstep (and to some point Apple's Cocoa) has a lot of other great features. Just check it out
Just to clarify: 'OpenStep' was the API. 'OPENSTEP' was the implementation (aka the OS).
OPENSTEP is a UNIX the same as NeXTStep was a UNIX and Mac OS X is a UNIX or Solaris is a UNIX...
There is a discussion about Pith on MacSlash.
In other news, Apple has updated it's iMac product line...