As a bonus, if you link to jQuery using the code.jquery.com URL, people's browsers will likely have it cached.
Please don't!
1) NoScript users hate you:-P 2) You are now depending on another site's availability for your site to function 3) I'm sure jquery.com or google.com or whoever is hosting your 3rd party script(s) loves your traffic information
I do agree that you should always specify an exact version of jQuery. Never use jquery.latest in place of jquery.1.2.3.
Pffft 8.x. Firefox 3.6 with TabKit rocks! (Well, it's pretty slow executing javascript and manipulating large DOM trees, but the side-tabs with grouping, indenting, coloring, bookmarking, searching are priceless.)
Software raid via mdadm is a good option. Setup a raid 1 or 1+0 md device for your two disks. E.g./dev/md1 = raid1 of/dev/sda1 +/dev/sdb1. Now format and use the/dev/md1 partition as full disk encryption, or a truecrypt container with ext4 inside, whatever you like. Now when one disk dies, mdadm emails you, and you can still read/write to the array (where only one disk is active).
I tend to partition and max out the available space on every drive, so LVM is an unnecessary layer for me.
You still need backup for file corruption, accidental deletion, or when both drives fail at the same time.
It'd be more awesome if the post was funny. +2 for style! The bolding, italicizing, and font changes are all spot-on, but the content is difficult to parse.
And I was looking forward to a good APK troll... and now sadly disappointed.
1999 called, they want their multiple windows back.
I don't see anything in the Chrome store that's even close to TabKit vertical tabs.
"Tabs Outliner" for Chrome is only a step up from "Side Tabs"... the tab bar is still horizontal and over crowded, and now I need to manage another window to focus when switching applications. It's decent, but needs to be in the same window as the browser and replace the existing tabs.
Are people really saving that much bandwidth to load 3rd party scripts? Shouldn't these JS "assets" sit well in a browser's cache? Even if loaded separately from 30 different sites, does it make a noticeable difference?
One day, these 3rd party sites that host static javascript libs will go down for several hours and cripple the web.
Even Ghostery can't block "required" 3rd party JS. These remote scripts are analytic data gatherers in exchange for bandwidth.
Agreed. Any decent outbound MTA should handle the 5xx error code properly and send their own Non Delivery Report to the original sender.
Many mail servers are returning 5xx error codes due to forward/reverse DNS not matching, unknown recipient, content spam filtering, etc. which are being handled just fine. Bouncing due to SPF failure is preferred.
I have heard the same with a single owner LLC. However, having multiple owners (not a married couple either) seems to reduce personal liability. (I have no evidence other than a book I read on company formation.)
Of course, multiple owner LLC (and especially s-corp) makes accounting and taxes a pain in the ass.
What? When you transfer a domain, you usually KEEP the existing nameservers. It's often not wise to use DNS provided by your registrar -- because then when transferring the domain, you need to pre-copy the zone to a new DNS provider.
Yes, you can move the DNS zone from a set of nameservers to another set of authoritative servers, and reducing TTLs for the SOA and NS records are advisable before making that change. However, the registry operators almost always set 48 hour TTLs on the set of authoritative nameservers, and that cannot be changed. Thus, you need the zone active on BOTH sets of nameservers for at least 48 hours.
There is no poisoning of any cache when either transferring a domain or moving the DNS zone to another provider. Various resolver caches may have different values for the SOA and NS records, but those caches are still correct and not poisoned by a 3rd party.
Of course you can always un-sign your zone. But the idea is that we all should sign our zones to prevent cache poisoning or MITM DNS responses or ISP filtering/wildcarding, etc.
Just like most mail server admins have enabled SPF via simple TXT records, only a few of those have implemented DKIM which requires signing each outbound email.
I do appreciate the beauty of a crazy chaotic and somewhat democratic process to create new standards (IETF/RFC) and implement them laissez-faire style on an as-needed basis.
If cache poisoning or abusive DNS filtering/hijacking was happening on a regular basis and reported widely in the [tech] media, DNSSEC would be implemented rapidly. There's just not enough threat to cover the pain of zone signing. Also, we have to trust the root server operators to never lose their keys...
Agreed. Implementing DNSSEC is a royal pain in the ass for the authoritative server operator. If it was easy, many would have done it.
Additionally, your domain registrar must support DNSSEC to list the digest records or even public keys with the registry so they can be listed in the TLD-root zone. Once you sign a domain, you cannot transfer the domain to a non-DNSSEC-implementing registrar.
Would either the parent or GP like to list some sites that were broken with DNSSEC? There are some decent tools to test DNSSEC queries, so I'm surprised the DNS admins for the broken zones have left it broken. There's not really any half-assed zone signing with DNSSEC, you either sign the entire zone or you don't.
Sure, he's passing the data in encrypted form so that only D1 and D3 can see what it really is, but does that really matter?
I guess you need to ask your ISP about their routers that are passing data in an encrypted form between an SSL server and a customer. Are they liable?
If the data is encrypted from endpoint to endpoint, does the Common Carrier status even apply? Meaning: do you need to be a common carrier to limit your liability when the payload is encrypted?
The only solution then is to "fix it as you go" -- thus, each "current project" action must re-write modules or add unit tests or create documentation to slowly dig your team out of their hole.
You don't have to re-write the entire application, or create huge flow charts showing how everything works, but a little here and a little there, along with some quick code reviews so the "right hand" of the team knows what the "left foot" is doing.
Would be rad if someone leaked this, then we could all take a peek instead of just The Watchers.
As a bonus, if you link to jQuery using the code.jquery.com URL, people's browsers will likely have it cached.
Please don't!
1) NoScript users hate you :-P
2) You are now depending on another site's availability for your site to function
3) I'm sure jquery.com or google.com or whoever is hosting your 3rd party script(s) loves your traffic information
I do agree that you should always specify an exact version of jQuery. Never use jquery.latest in place of jquery.1.2.3.
Pffft 8.x. Firefox 3.6 with TabKit rocks! (Well, it's pretty slow executing javascript and manipulating large DOM trees, but the side-tabs with grouping, indenting, coloring, bookmarking, searching are priceless.)
I hope you're only making coffee 6-8 times a day for yourself and not "experimenting" with the break room coffee.
And if you are making it only for yourself... that might be too much caffeine. How do you sleep at night?
See comment to your original post: http://ask.slashdot.org/comments.pl?sid=3575755&cid=43283631
Software raid via mdadm is a good option. Setup a raid 1 or 1+0 md device for your two disks. E.g. /dev/md1 = raid1 of /dev/sda1 + /dev/sdb1. Now format and use the /dev/md1 partition as full disk encryption, or a truecrypt container with ext4 inside, whatever you like. Now when one disk dies, mdadm emails you, and you can still read/write to the array (where only one disk is active).
I tend to partition and max out the available space on every drive, so LVM is an unnecessary layer for me.
You still need backup for file corruption, accidental deletion, or when both drives fail at the same time.
Slashcode needs to fix the sig.
It'd be more awesome if the post was funny. +2 for style! The bolding, italicizing, and font changes are all spot-on, but the content is difficult to parse.
And I was looking forward to a good APK troll... and now sadly disappointed.
But do you have any open ports on your router?
From the paper:
420 Million pingable IPs + 36 Million more that had one or more ports open
Your router may be counted in the 36 million non-pingable but still had an open port.
Exactly. I assume most adult readers are aware of the heavy Christian influence in CS Lewis works.
When you're a kid reading books, it's easy to overlook symbolism to enjoy the story.
Same example!
Orson Scott Card is also Mormon. Some of his beliefs are pretty clear after the first book of the Ender's series.
Like this dark one or this light one?
1999 called, they want their multiple windows back.
I don't see anything in the Chrome store that's even close to TabKit vertical tabs.
"Tabs Outliner" for Chrome is only a step up from "Side Tabs"... the tab bar is still horizontal and over crowded, and now I need to manage another window to focus when switching applications. It's decent, but needs to be in the same window as the browser and replace the existing tabs.
And, they've had side tabs for many years, with thumbnails too.
I don't understand how anyone uses Chrome (and variants) for Real(TM) web browsing. TabKit+ on Firefox seems to be the only power-browsing tool.
Gotta spend money to make money! But more importantly, you have to enjoy the niche.
Are people really saving that much bandwidth to load 3rd party scripts? Shouldn't these JS "assets" sit well in a browser's cache? Even if loaded separately from 30 different sites, does it make a noticeable difference?
One day, these 3rd party sites that host static javascript libs will go down for several hours and cripple the web.
Even Ghostery can't block "required" 3rd party JS. These remote scripts are analytic data gatherers in exchange for bandwidth.
Agreed. Any decent outbound MTA should handle the 5xx error code properly and send their own Non Delivery Report to the original sender.
Many mail servers are returning 5xx error codes due to forward/reverse DNS not matching, unknown recipient, content spam filtering, etc. which are being handled just fine. Bouncing due to SPF failure is preferred.
Why build an engine, when you can steal one!
I have heard the same with a single owner LLC. However, having multiple owners (not a married couple either) seems to reduce personal liability. (I have no evidence other than a book I read on company formation.)
Of course, multiple owner LLC (and especially s-corp) makes accounting and taxes a pain in the ass.
What? When you transfer a domain, you usually KEEP the existing nameservers. It's often not wise to use DNS provided by your registrar -- because then when transferring the domain, you need to pre-copy the zone to a new DNS provider.
Yes, you can move the DNS zone from a set of nameservers to another set of authoritative servers, and reducing TTLs for the SOA and NS records are advisable before making that change. However, the registry operators almost always set 48 hour TTLs on the set of authoritative nameservers, and that cannot be changed. Thus, you need the zone active on BOTH sets of nameservers for at least 48 hours.
There is no poisoning of any cache when either transferring a domain or moving the DNS zone to another provider. Various resolver caches may have different values for the SOA and NS records, but those caches are still correct and not poisoned by a 3rd party.
Of course you can always un-sign your zone. But the idea is that we all should sign our zones to prevent cache poisoning or MITM DNS responses or ISP filtering/wildcarding, etc.
Just like most mail server admins have enabled SPF via simple TXT records, only a few of those have implemented DKIM which requires signing each outbound email.
I do appreciate the beauty of a crazy chaotic and somewhat democratic process to create new standards (IETF/RFC) and implement them laissez-faire style on an as-needed basis.
If cache poisoning or abusive DNS filtering/hijacking was happening on a regular basis and reported widely in the [tech] media, DNSSEC would be implemented rapidly. There's just not enough threat to cover the pain of zone signing. Also, we have to trust the root server operators to never lose their keys...
Agreed. Implementing DNSSEC is a royal pain in the ass for the authoritative server operator. If it was easy, many would have done it.
Additionally, your domain registrar must support DNSSEC to list the digest records or even public keys with the registry so they can be listed in the TLD-root zone. Once you sign a domain, you cannot transfer the domain to a non-DNSSEC-implementing registrar.
Would either the parent or GP like to list some sites that were broken with DNSSEC? There are some decent tools to test DNSSEC queries, so I'm surprised the DNS admins for the broken zones have left it broken. There's not really any half-assed zone signing with DNSSEC, you either sign the entire zone or you don't.
Sure, he's passing the data in encrypted form so that only D1 and D3 can see what it really is, but does that really matter?
I guess you need to ask your ISP about their routers that are passing data in an encrypted form between an SSL server and a customer. Are they liable?
If the data is encrypted from endpoint to endpoint, does the Common Carrier status even apply? Meaning: do you need to be a common carrier to limit your liability when the payload is encrypted?
The only solution then is to "fix it as you go" -- thus, each "current project" action must re-write modules or add unit tests or create documentation to slowly dig your team out of their hole.
You don't have to re-write the entire application, or create huge flow charts showing how everything works, but a little here and a little there, along with some quick code reviews so the "right hand" of the team knows what the "left foot" is doing.
Good luck!