Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:I'm okay with it. (Score 2, Informative) 989

As long as they also include every other creation story. There should be text from scientology, islam, hinduism, buddhism, and thousands of other creation myths from all over the world, in a separate book called "Creationism".

AFAIK, Buddhism has no creation myth of its own. In some particular cultures it may have adopted the prevailing local myths as metaphors, much like the local gods and goddesses were adopted as representative of aspects of the human psyche.

Theologists debate whether Buddhism can even be considered a religion because there is no belief in god. It slides in when you widen the scope to include a "belief in salvation" which in the case of Buddhists, is enlightenment and nirvana (non-existence).

Comment Re:pattern? (Score 2, Interesting) 220

Some people believe that toilets don't allow for complete elimination and are the source of a lot of colon cancer.

For my part, I've realized that after a lot of years camping and having to squat over a hole I dig, that at some point my knees simply won't let me do that any more. I've come to believe that maybe people die younger in parts of the world that lack sit down toilets and remember this quote by Charles Bukowski:

Sex is interesting, but it's not totally important. I mean it's not even as important (physically) as excretion. A man can go seventy years without a piece of ass, but he can die in a week without a bowel movement.
- Charles Bukowski

Comment This happened to us once (Score 1) 167

Well, not the hostages part. But we lost a T1 circuit at a client site when burglars attempted to break into the Credit Union next door. Being wholly unclear of the purpose of an alarm circuit, they cut all the copper going into the business park. That didn't work out so great for them, since it cause an alarm that the police responded to.

Comment Re:Things I look for (Score 1) 456

That happens occasionally. My preferred solution (if they don't have a VPS) is to point their PHP app to forums.foo.com while leaving their .NET at www.foo.com (or vice versa).

So yes, I'd rather maintain two separate logins on two separate servers than install PHP on a windows server.

I'm sure it runs fine, I just don't want to deal with patching third-party apps on Windows. If there's a php vuln, it will be covered in an update with my linux package manager. If there's a .NET vuln, it will be covered (eventually) in a Windows Update.

It's all about scalability and consistency in the big picture.

Comment Re:Things I look for (Score 1) 456

Do they use Linux only? I only want Linux hosting, and mixed providers are always trying to push you over into Windows hosting because they're being incentivized to do so. I've been around and don't need to hear that pitch again.

Eh, that may be true in some cases. My employer provides hosting on linux and windows because some of our customers (who are also buying our bandwidth at their offices and want a single point of billing/support for all their Internet services) are developing .NET apps and want the native platform.

So, quite often the Windows is there simply to appease the customers who want it. We just as often go the other way. When customers ask us to install PHP on their windows host, we point them to the linux servers instead (as I have a rule about keeping technologies on their native platforms whenever possible).

Comment I remember... (Score 1) 131

Back in the 80s I recall reading an article in OMNI that debunked many of the popular sci-fi myths. Among the notable points:

* Invisibility implies blindness since your retinas wouldn't absorb any light.

* Time travel without space travel would suck too, since you'd most likely re-materialize in empty space.

* Giant insects will collapse under the own weight.

Comment Re:I'd much rather... (Score 1) 636

The market will not come up a solution for this, because it is the market that is doing it.

An interesting analogy here.... a couple nights ago I was driving on I-25 in Denver and noticed that there has been a proliferation of ultra-bright LED signs. These are clearly distractions at night (to the point of being almost blinding if you look directly at them).

So I resolved to punish the two businesses that I don't do business with to begin with, by remembering their names in case I should happen to find myself in their market. The first one I've identified is Coyote Motorsports. The other is a mattress company, but I'm not completely certain now that it is who I think it is, so I'll wait till I see it again to confirm.

Likewise I'll never buy insurance from GEICO because their airplane banner advertisements have become a noise nuisance over my apartment every weekend all summer long (circling over about every half hour or more all day long).

Comment Re:Theres one technical point (Score 1) 620

Wrong. You can setup an https port on any port you like. The 'https' just tells it to use the Secure HTTP protocol as opposed to the HTTP protocol. It'll still honor and work with ports other than 443. Just specify the port in the URL.

Yes, that is the entire purpose of the SRV concept. I am aware of how to configure apache and run SSL on alternate ports.

I stand by the belief that HTTPS virtual hosting on a single IP address is not a viable option for hosting providers, because there is no way to communicate alternate port numbers to every possible user on the Internet who might want to connect to it.

I get regular client requests asking me to map www.foo.com to 1.2.3.4:444

Then I have to explain to them why that doesn't work, and we go down the sales process of selling them a better firewall that can have more than one IP address assigned to it. Because the clients are unwilling to tell their clients "Our secure website is www.foo.com:444". And honestly, I can't blame them. I wouldn't accept that for my website.

Comment Re:Theres one technical point (Score 1) 620

what's stopping people from hosting http and https on the same ip?

Nothing. It is done all the time. The problem is hosting multiple https sites with different SSL certificates on the same IP.

Though in my experience at least 75% or more of that SSL is used to encrypt credit cards or other sensitive financial information, at which point security concerns should really dictate a dedicated platform anyway. With virtualization's rise there is a greater tendency in that direction now even when SSL isn't used.

Overall that means I'm seeing our shared web hosting products being split up, and consuming more IPs over time.

Comment Re:Theres one technical point (Score 1) 620

You're *deploying* behind NAT? Just get enough IPs to run your sites and stop being a cheapskate.

I administer roughly 32k IPs in about 40 aggregates that we advertise via BGP. I have customers who occasionally come to me with this kind of scenario, yes. Often that's an upgrade from a SOHO firewall to pfsense, since most of the SOHO stuff can't handle more than one IP (note: I'm pointing out now how we benefit financially by selling more services with the existing HTTPS limitations, even as I'm arguing they are wasteful of the larger shared IPv4 resources).

As a service provider, I dislike having to provision a unique IP for each SSL website we host, because it is wasteful (though, again, profitable too). It could have been done with SRV records, but that wasn't an option until Feb 2000.

I'm a year older than the Internet. Hopefully we'll get to IPv6 before I hit retirement. I'm not holding my breath.

Comment Re:Theres one technical point (Score 2, Informative) 620

How would it allow named virtual hosts? The only thing you have at the network layer is the IP address that the message was sent to, that's why HTTPS virtual hosts is difficult to implement.

When a client makes an initial HTTPS request, there is a high likelihood that they want to submit confidential information. Therefore the browser and server perform an SSL handshake so that the initial client's first GET/POST/WHATEVER is encrypted.

Virtual hosting requires looking at the client-supplied host header value in that GET/POST. In order to return the right SSL certificate we need that host header value to determine which site's cert to serve. But we can't get at that host header value until the SSL negotiation has completed. So virtual hosting for HTTPS on a single IP is simply not possible at present due to this catch-22.

With the idea of SRV records for port values, virtual hosting for HTTPS becomes possible. I simply map each new site's certificate to a new port number. When the client makes a connection, we already know in advance what certificate they are looking for because only one is bound to each specific port.

Under the current schema, we need a discrete IP address per SSL certificate in order to avoid this problem, but with SRV's, we can use a port number to hold the same mapping, without requiring the client to put in :port (which would work today for virtual HTTPS hosting if we could get everyone in the world to somehow know in advance what port number they want).

I suppose a variant of this is possible today. Imagine I have a storefront at foo.com. A client enters store and puts stuff in their cart. They never enter my store by typing HTTPS in their browser. My site could hardcode the link to https://www.foo.com:444/ inside the "Checkout" link, and I could have many other SSL hosts all sharing the same IP in that manner. I can understand why web hosts and their clients wouldn't really like this idea. But the SRV method would be elegant enough to be adopted, IMHO.

Comment Re:Theres one technical point (Score 1) 620

Not sure why your post is modded insightful.

Just because a capability exists doesn't mean it must be used. I put up ad-hoc testing servers every day. I address them by IP address, and optionally, port. Giving me the flexibility to use SRV records for port information like SIP does would be a very nice thing for deployment. It wouldn't change how I actually test in the slightest. I'd still go to http://192.168.1.2:81/ for testing, and then later if this ad-hoc server needs to go live and I have a single NAT IP with port 80 already spoken for, I'd be able to easily host multiple web servers without requiring the end-users to type in the :port on every URL.

I don't expect to see this changed, but it is still a nice idea that could conserve a large amount of IP addresses currently wasted on SSL website hosting.

Slashdot Top Deals

You knew the job was dangerous when you took it, Fred. -- Superchicken

Working...