Here in Norway pretty much all medium-sized and larger businesses have agreements with a cell phone company that basically means that all company-internal calls are free, as well as all external calls made via cell towers located around their office locations.
I.e. all the calls that you would have used a land line phone for in the old days.
We have of course never had the horrible "cell phone receiver pays" system used in the US, partly because all cell phones have gotten numbers from a couple of separate ranges, never used for land-line phones, so that we always knew if we were calling a fixed or mobile phone.
The last time I bought a cell phone with a contract clause must have been 5+ years ago, it was for one of my kids.
We did measure some slowdown of applications, but mostly in the single-digit percentage range.
This was simply because most applications those days did all their work in memory, only Microsoft's virtual disk swapper would use the disk during normal operation, and then only in case you suddenly needed a lot of free memory space.
Bulk load of application and data files did slow down a bit, but significantly less than 50%, i.e. the hard drive did not suddenly become half as fast even for bulk transfers.
When I was involved in the AES process more than 10 years ago, one of our targets was to optimize the crypto code so that a 1996 vintage PentiumPro could handle a 100 Mbit/s full-duplex communication line, or correspondingly about 20 MB/s of disk en/de-cryption.
Today full disk crypto is effectively free, except in power usage, since all computers have multiple cores, most of which are idle even when an application is working hard, and a single core can keep up with the fastest available (spinning) hard drive. A modern i7 core with the AES extensions can do the crypto without getting hot.:-)
I was in charge of testing/verification of full disk crypto when my then-employer (Hydro) mandated it almost 20 years ago:
At that time 5 vendors made it through our pre-qualification tests, among these I was able to trivially break 3 of them (replace a conditional branch with its opposite), one took 20 minutes and only Utmaco's SafeGuard Easy had done a proper security design, where the user password was used as (part of) the seed for the key used to decrypt a copy of the master disk key.
I.e. the system _must_ be safe against attack from anyone, including the vendor!
I wrote a longer post about this the previous time the same issue came up on/.
The reason that over-50 crowd is asking for help is almost certainly due to deteriorating eyesight and glasses!
First of all, a 50 year old needs 3X the light level as a 20-30 year old, second the progressive glasses most of has to start wearing at this time takes a huge slice out of the normal visual field:
I used to be able to easily locate things that were near the edge of my visual field, with my current (very good/expensive) glasses I need to turn my entire head, not just flick a glance sidewise.
This does mean that I find it far harder to locate items in the Supermarket/grocery store, unless it is the local one where I know where everything is located.
It also means that I will ask store attendants for directions to stuff that I would simply find on my own 15 years ago, simply because I know it will probably save me a lot of time.
I've been programming since 1977, and I'm still doing it, although my job description hasn't had "programmer" in it since 1984:
(My first job out of university was writing digital signal analysis sw for a research institute, I did that from 1981 to 84.)
During the last few years I've been involved with crypto (AES) and graphics optimization, multicore computing as well as a few programming competitions: I suspect that I'm probably 20 years older than most of the other quarter/semi-finalists at the two Facebook Hacker Challenges.
The main/only/sufficient reason is of course that I love doing it!
Solving puzzles is something I would pay to do, so getting paid is a great deal imho.
(My official job these days is to be the in-house IT troubleshooter for a very large Norwegian IT company, I manage to sneak in some programming here as well, often some Perl to analyze network trace/log files.)
I have used SeaMonkey from the day they made the fork, relatively happy even if I nowadays also use Chrome for better cross-instance isolation.
I also have Opera installed, I use that exclusively for online banking.
I do like the fact that in SeaMonkey I can right-click a link in a mail/news msg and do "Open in a New Window".
I also enjoy knowing that SeaMonkey is non-mainstream, even if that isn't much a security feature these days when 90-99% of the browser code is shared with Firefox.
Since it will be totally limited by disk IO, the language you choose doesn't really matter, as long as you make sure that you never read each file more than once:
1) Recursive scan of all disks/directories, saving just file name and size plus a pointer to the directory you found it in.
If you have multiple physical disks you can run this in parallel, one task/thread for each disk.
2) Sort the list by file size.
3) For each file size with multiple entries do:
3a) How many matches are there and how large are they?
3a1) Just two files: Read them both in parallel, using a block size of 1MB or more in order to avoid extra disk seeks, and compare directly. Exit on first difference of course!
3a2) 3 or more files: Read them all interleaved, still using a 1MB+ block size. For each block calculate a CRC32 or secure hash, compare these at the end of each block iteration. When a single file differs from the rest, it is unique. When two or more are equal but still different from the majority of the group, recurse into a new copy of the scanning function that checks the smallest group, then upon return go on with the rest.
It should be obvious that your scanning function needs to accept an array of open file handles/descriptor plus an offset to start the scanning process at, thus making it easy to call it recursively to check the tails of a sub-array!
(A possible problem can occur if you have _very_ many files of the same size, in that the operating system could run out of file handles for simultaneously open files! In that case I'd fall back on passing in file paths instead of open handles and take the hit of re-opening each file for each block to be read. I would also increase the block size significantly, into the 10-100 MB range, so that everything except big ISOs and similar would be read in a single access. The same process is probably optimal for file sizes less than the minimum block size.)
This algorithm should be able to do what you need in significantly less time than you'd need to just read everything once. I'd estimate about 50 MB/s effective reading speed, so if everything is on a single disk (4.9 TB? Not very likely!) and every single file size has multiple entries that only differ in the last byte, you would need 100 K seconds, or a little more than a day. My guess is you should easily finish overnight!
Genda wrote: > Wouldn't you also say, that having heavy math chops allows you to see clearly when the line from problem to solution is non-optimal?
Oh, absolutely!
Big O notation/thinking becomes instinctive after some years, making it physically painful to code a brute force/O(n*n) algorithm when you can almost always get to O(n*log n) or even better.
Terje PS. My MSEE was in fiber optics and required solving the Schrödinger equation for the light coming out of the end of a mono-modus optical fiber. I don't think I've ever needed this level of math since then.:-)
If you just want to make a living, then you'll probably never need any higher math.
OTOH, if you are at all serious about programming as something you want to be really good at, then you need a _lot_ more.
I've worked with low-level game code (Quake asm), with video & audio codecs (MPEG2, h.264, ogg vorbis), with crypto (one of the AES candidates) and I wrote most of the code for the compiler sw workaround for the Pentium FDIV bug.
I doubled the speed of a Computational Fluid Chemistry code base, so that simulations ran in half a week instead of 7 days.
I've also won a couple of international code optimization contests.
The key here is that except for the h.264 optimization all of this has been pro bono, my daily job at a Norwegian IT company has almost never _required_ me to know a lot of math, but having math as a hobby means that I tend to spot all the bogus calculations in Powerpoint presentations.:-)
My wife worked for 9 years optimizing public transport in Oslo, Norway.
One of the key items behind a significant speedup for both buses and trams was a system where each vehicle would signal ahead a given distance before arriving at an intersection, again as it entered, and finally as it left. If you visit Oslo and sit up front in a bus or tram you can see the visual feedback the driver gets: A single white LED mounted near the top of the traffic signal will light up, either blinking or in a steady state.
There is (of course) a web site and a mobile app which will give you real-time information about any given bus/tram/line/stop, as well as rolling displays at all major stops that show the same info.
Before I got my first pure IT job (back in 1984) I was developing sw for my father-in-law's company, I mentioned this during the interview and got an exception clause that would allow me to keep on supporting that software.
I have since then had a number of offers of new jobs/gone to multiple interviews: I have always mentioned the situation with my father-in-law and it has never been a problem.
At the same time (1982-1984) I had also developed some terminal emulation/file transfer software which was moderately successful, I sold a site license to my new employer which at the same time gave me the rights to go on maintaining it and selling it to other customers. During the next 4-5 years those external sales paid for our little mountain cabin near Rjukan, Telemark.
Last year I sent an email to IEEE saying that I would leave the organization if they continued holding research papers hostage behind pay walls.
I.e. authors were told that in order to get published they would have to assign their copyrights to IEEE and would have to remove any freely available copies on their own personal web page.
I did imply that "Flat Earth" calculations are only valid withing a limited distance, like an UTM zone, but this is still several 100 km.
For most GIS style queries exact results really don't matter, i.e. if you happen to select a hospital that is 20001 m away and/or exclude one that is 19999 m away, this is still fine, simply because the origin point is almost never defined with such accuracy, and neither are the stored coordinates for people or hospitals.
If you insist on exact distances then you need to go to Vincenty or a similar formula, since classical Great Circle calculations still have errors.
This is an iterative process consisting of about 75 lines of code, including 2 calls each to sin/cos/sqrt in the setup code, then sin/cos/sqrt/atan2 in the inner loop, followed by a couple of atan2 and a sqrt call at the end. I.e. we're talking about thousands of clock cycles for each calculation.
This means that the exact function is several orders of magnitude slower than the approximate version, so if you insist on handling all the borderline cases exactly, the best approach is to use an approximate distance selector that is safely too large (maybe a meter or two over 20 km), then filter the results by re-checking any that happened to be borderline (i.e. within 2-4 m of the limit). The last set, of borderline distances, will most often be empty.
With this approach you can get exact results with a query speed that is effectively the same as for a simple UTM distance calculation!
If it is just a set of proximity queries, then you could almost do that with search&replace on your SQL code
I.e.if you can store coordinates in UTM distance calculations become dead simple:
"select * from hospitals where (lat-targetLat)*(lat-targetLat)+(lon-targetLon)*(lon-targetLon) maxDist*maxDist"
Working with degrees makes it a bit harder, but as long as maximum distances are within a few 100 km you can get away with a simple cos(targetLat*deg2rad) scaling of the longitude values.
I am 54, and I started to become passionate about programming in 1977, initially writing Fortran 2 on punched cards, then I went on to Simula, Pascal, assembler, C, etc, etc.
During the eighties and first half of the nineties I was probably best known as one of the better x86 asm programmers.
Since then I have never stopped programming, even though most of my professional career over the last 15-20 years have been involved with solving performance problems in other people's code and/or systems. I still frequent comp.lang.asm.x86 and comp.arch, discussing algorithms, optimization and computer architecture.
I do hope/believe that I could still get a new job if I wanted to move away from where I am.
In the PDF you'll see that the leap week they propose is based on the current Gregorian calendar
"Note: the “Extra-Week Years” are every year in which the Gregorian calendar begins or ends on a Thursday:
2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088,
2093, 2099, 2105, 2111, 2116, 2122, 2128, 2133, 2139, 2144, 2150, 2156, 2161, 2167 "
I.e. in order to use this calendar you would still have to maintain the current calendar in parallel, so you gain the "benefit" of having to work with two different calendar systems.:-(
Norway is even further north than Canada, we have _very_ little flat land at low elevations close to the ocean, and we get pretty much all our electricity from hydro-electric plants.
We will still get badly hurt by increasing global temperatures:
The first result of a temperature rise is a large increase in the amount of severe weather, something which you could argue have already started. In the US that means longer and much more severe tornado seasons, in Norway we get severe river flooding from melt water (both snow and glaciers) combined with heavy rain periods.
Yes, our agricultural growing season will increase, but with only 2.7% potentially arable land, this really doesn't make much difference.
I first heard about this conjecture many years ago (25?) and did what most geeks would do; I wrote a program to test all odd integer values and check that they did in fact reach 1.
The obvious approach is to remember the count for each value as you try them, then check any intermediate result against this table: If found, just add that value to the current count and store the result.
This approach breaks down when you want to test starting values much larger than 2^32, because the space to store the table becomes larger than available memory.
One of the first optimizations is to realize that the result of taking 3n+1 starting from an odd (n) will always be even, so you can simply include the following n/2 (a shift) and increase the count, while getting rid of the multiplication by 3:
Odd(n):
n = 2m+1
3n+1 = 6m + 4
(3n+1)/2 = 3m + 2 = n + (n>>1) + 1
In asm this can be simplified to:
again:
shr eax,1;; Assume even, so divide by two and shift the bottom bit into carry
jz done;; If the result of the shift was zero, we're done!
inc edx;; Increment number of steps
jnc again;; No carry means even input, so go back up
inc edx;; One extra increment;; The starting value was odd, so now we need to multiply by 3 and add 2:
lea eax,[eax+eax*2+2]
jmp again
done:
A much more sophisticated step is to see that the next N operations are determined by the bottom N bits of the current value (as long as there are more than N bits available), basically allowing you to convert those N operations into a multiplication, an add and a shift right.
Next you realize that the intermediate values can very quickly overflow a 32-bit unsigned integer, and even using 64-bit values does not get you very far.
My approach back in those days was to use a variable number of 32-bit counters:
With a single counter I check for getting to 1 or overflowing so I need to use two counters.
With two (or more) counters I test for the top counter becoming zero, allowing me to reduce the number of counters, or for overflow forcing another incease.
All of this is of course much easier in asm than C,since you can use the ADD/ADC combination to perform arbitrary precision
a) Even with small amounts of hidden data (20 MB in 160 GB was quoted), you will still end up with an _extremely_ fragmented file system:
Each hidden bit requires either a sequential or fragmented block placement, which means that 20 MB needs 160 Mbit or 160 million frag/nofrag chaining decisions.
This works out to one such block per kB of disk space, but since the FAT32 filesystem normally uses 4 KB (or larger) clusters, you would have to decrease the block size to either 1 KB or 512 bytes (the sector size, so the minimum possible).
Since the (presumably compressed and encrypted) data to be hidden will have 50% 0 and 1 bits, the allocation run lengths in the file system will average just two clusters, this would be extremely obvious on any low-level scan of the file system.
I.e. you could make this system work, but only in order to hide a few KB of data, not MB!
There are literally millions of web sites, like my own, that are based on a shared hosting provider, right?
This means that all the domains on a single server starts out by sharing a single IP address. This works perfectly well for HTTP, since the web server will see which domain the client is trying to communicate with, so it can respond with the proper set of pages.
For HTTPS otoh you need something more:
a) A signed (not self-signed!) SSL cert, which means that you have to hand over a not insignificant amount of cash every year or two, otherwise your server will cause strong warnings on every browser out there.
b) A dedicated IP address, since a standard SSL certificate is bound to a particular address.
Personally I am paying about $6-7 per month in total for 5+ domains hosted with Dreamhost, putting them all on HTTPS would make it maybe 10X more expensive.
The solution to (a) above is to make it much easier to accept self-signed certs in browsers, while (b) will be solved by ipv6.
Slashdot Mirror
Here in Norway pretty much all medium-sized and larger businesses have agreements with a cell phone company that basically means that all company-internal calls are free, as well as all external calls made via cell towers located around their office locations.
I.e. all the calls that you would have used a land line phone for in the old days.
We have of course never had the horrible "cell phone receiver pays" system used in the US, partly because all cell phones have gotten numbers from a couple of separate ranges, never used for land-line phones, so that we always knew if we were calling a fixed or mobile phone.
The last time I bought a cell phone with a contract clause must have been 5+ years ago, it was for one of my kids.
Terje
No, the resource usage was not "extreme":
We did measure some slowdown of applications, but mostly in the single-digit percentage range.
This was simply because most applications those days did all their work in memory, only Microsoft's virtual disk swapper would use the disk during normal operation, and then only in case you suddenly needed a lot of free memory space.
Bulk load of application and data files did slow down a bit, but significantly less than 50%, i.e. the hard drive did not suddenly become half as fast even for bulk transfers.
When I was involved in the AES process more than 10 years ago, one of our targets was to optimize the crypto code so that a 1996 vintage PentiumPro could handle a 100 Mbit/s full-duplex communication line, or correspondingly about 20 MB/s of disk en/de-cryption.
Today full disk crypto is effectively free, except in power usage, since all computers have multiple cores, most of which are idle even when an application is working hard, and a single core can keep up with the fastest available (spinning) hard drive. A modern i7 core with the AES extensions can do the crypto without getting hot. :-)
Terje
I was in charge of testing/verification of full disk crypto when my then-employer (Hydro) mandated it almost 20 years ago:
At that time 5 vendors made it through our pre-qualification tests, among these I was able to trivially break 3 of them (replace a conditional branch with its opposite), one took 20 minutes and only Utmaco's SafeGuard Easy had done a proper security design, where the user password was used as (part of) the seed for the key used to decrypt a copy of the master disk key.
I.e. the system _must_ be safe against attack from anyone, including the vendor!
I wrote a longer post about this the previous time the same issue came up on /.
Terje
The reason that over-50 crowd is asking for help is almost certainly due to deteriorating eyesight and glasses!
First of all, a 50 year old needs 3X the light level as a 20-30 year old, second the progressive glasses most of has to start wearing at this time takes a huge slice out of the normal visual field:
I used to be able to easily locate things that were near the edge of my visual field, with my current (very good/expensive) glasses I need to turn my entire head, not just flick a glance sidewise.
This does mean that I find it far harder to locate items in the Supermarket/grocery store, unless it is the local one where I know where everything is located.
It also means that I will ask store attendants for directions to stuff that I would simply find on my own 15 years ago, simply because I know it will probably save me a lot of time.
Terje
I've been programming since 1977, and I'm still doing it, although my job description hasn't had "programmer" in it since 1984:
(My first job out of university was writing digital signal analysis sw for a research institute, I did that from 1981 to 84.)
During the last few years I've been involved with crypto (AES) and graphics optimization, multicore computing as well as a few programming competitions:
I suspect that I'm probably 20 years older than most of the other quarter/semi-finalists at the two Facebook Hacker Challenges.
The main/only/sufficient reason is of course that I love doing it!
Solving puzzles is something I would pay to do, so getting paid is a great deal imho.
(My official job these days is to be the in-house IT troubleshooter for a very large Norwegian IT company, I manage to sneak in some programming here as well, often some Perl to analyze network trace/log files.)
Terje
I have used SeaMonkey from the day they made the fork, relatively happy even if I nowadays also use Chrome for better cross-instance isolation.
I also have Opera installed, I use that exclusively for online banking.
I do like the fact that in SeaMonkey I can right-click a link in a mail/news msg and do "Open in a New Window".
I also enjoy knowing that SeaMonkey is non-mainstream, even if that isn't much a security feature these days when 90-99% of the browser code is shared with Firefox.
Terje
This is a very fun programming task!
Since it will be totally limited by disk IO, the language you choose doesn't really matter, as long as you make sure that you never read each file more than once:
1) Recursive scan of all disks/directories, saving just file name and size plus a pointer to the directory you found it in.
If you have multiple physical disks you can run this in parallel, one task/thread for each disk.
2) Sort the list by file size.
3) For each file size with multiple entries do:
3a) How many matches are there and how large are they?
3a1) Just two files: Read them both in parallel, using a block size of 1MB or more in order to avoid extra disk seeks, and compare directly. Exit on first difference of course!
3a2) 3 or more files: Read them all interleaved, still using a 1MB+ block size. For each block calculate a CRC32 or secure hash, compare these at the end of each block iteration. When a single file differs from the rest, it is unique.
When two or more are equal but still different from the majority of the group, recurse into a new copy of the scanning function that checks the smallest group, then upon return go on with the rest.
It should be obvious that your scanning function needs to accept an array of open file handles/descriptor plus an offset to start the scanning process at, thus making it easy to call it recursively to check the tails of a sub-array!
(A possible problem can occur if you have _very_ many files of the same size, in that the operating system could run out of file handles for simultaneously open files! In that case I'd fall back on passing in file paths instead of open handles and take the hit of re-opening each file for each block to be read. I would also increase the block size significantly, into the 10-100 MB range, so that everything except big ISOs and similar would be read in a single access. The same process is probably optimal for file sizes less than the minimum block size.)
This algorithm should be able to do what you need in significantly less time than you'd need to just read everything once. I'd estimate about 50 MB/s effective reading speed, so if everything is on a single disk (4.9 TB? Not very likely!) and every single file size has multiple entries that only differ in the last byte, you would need 100 K seconds, or a little more than a day. My guess is you should easily finish overnight!
Terje
I would guess that simply tailgating a big van/lorry past each camera would be sufficient to make the licence plate unreadable.
I know that this happens on some automated toll roads here in Norway...
Terje
Genda wrote:
> Wouldn't you also say, that having heavy math chops allows you to see clearly when the line from problem to solution is non-optimal?
Oh, absolutely!
Big O notation/thinking becomes instinctive after some years, making it physically painful to code a brute force/O(n*n) algorithm when you can almost always get to O(n*log n) or even better.
Terje :-)
PS. My MSEE was in fiber optics and required solving the Schrödinger equation for the light coming out of the end of a mono-modus optical fiber. I don't think I've ever needed this level of math since then.
If you just want to make a living, then you'll probably never need any higher math.
OTOH, if you are at all serious about programming as something you want to be really good at, then you need a _lot_ more.
I've worked with low-level game code (Quake asm), with video & audio codecs (MPEG2, h.264, ogg vorbis), with crypto (one of the AES candidates) and I wrote most of the code for the compiler sw workaround for the Pentium FDIV bug.
I doubled the speed of a Computational Fluid Chemistry code base, so that simulations ran in half a week instead of 7 days.
I've also won a couple of international code optimization contests.
The key here is that except for the h.264 optimization all of this has been pro bono, my daily job at a Norwegian IT company has almost never _required_ me to know a lot of math, but having math as a hobby means that I tend to spot all the bogus calculations in Powerpoint presentations. :-)
Terje
...but only for public transport!
My wife worked for 9 years optimizing public transport in Oslo, Norway.
One of the key items behind a significant speedup for both buses and trams was a system where each vehicle would signal ahead a given distance before arriving at an intersection, again as it entered, and finally as it left. If you visit Oslo and sit up front in a bus or tram you can see the visual feedback the driver gets: A single white LED mounted near the top of the traffic signal will light up, either blinking or in a steady state.
There is (of course) a web site and a mobile app which will give you real-time information about any given bus/tram/line/stop, as well as rolling displays at all major stops that show the same info.
http://trafikanten.no/ and http://m.trafikanten.no/
Terje
Before I got my first pure IT job (back in 1984) I was developing sw for my father-in-law's company, I mentioned this during the interview and got an exception clause that would allow me to keep on supporting that software.
I have since then had a number of offers of new jobs/gone to multiple interviews: I have always mentioned the situation with my father-in-law and it has never been a problem.
At the same time (1982-1984) I had also developed some terminal emulation/file transfer software which was moderately successful, I sold a site license to my new employer which at the same time gave me the rights to go on maintaining it and selling it to other customers. During the next 4-5 years those external sales paid for our little mountain cabin near Rjukan, Telemark.
Terje
Last year I sent an email to IEEE saying that I would leave the organization if they continued holding research papers hostage behind pay walls.
I.e. authors were told that in order to get published they would have to assign their copyrights to IEEE and would have to remove any freely available copies on their own personal web page.
See also http://politics.slashdot.org/story/10/06/30/2027226/ieee-supports-software-patents-in-wake-of-bilski and http://news.slashdot.org/story/10/06/15/177217/ieee-working-group-considers-kinder-gentler-drm about locking research behind DRM gates.
With very little visible change to their attitudes, I decided to leave.
Terje
I did imply that "Flat Earth" calculations are only valid withing a limited distance, like an UTM zone, but this is still several 100 km.
For most GIS style queries exact results really don't matter, i.e. if you happen to select a hospital that is 20001 m away and/or exclude one that is 19999 m away, this is still fine, simply because the origin point is almost never defined with such accuracy, and neither are the stored coordinates for people or hospitals.
If you insist on exact distances then you need to go to Vincenty or a similar formula, since classical Great Circle calculations still have errors.
See http://en.wikipedia.org/wiki/Vincenty%27s_formulae
This is an iterative process consisting of about 75 lines of code, including 2 calls each to sin/cos/sqrt in the setup code, then sin/cos/sqrt/atan2 in the inner loop, followed by a couple of atan2 and a sqrt call at the end. I.e. we're talking about thousands of clock cycles for each calculation.
This means that the exact function is several orders of magnitude slower than the approximate version, so if you insist on handling all the borderline cases exactly, the best approach is to use an approximate distance selector that is safely too large (maybe a meter or two over 20 km), then filter the results by re-checking any that happened to be borderline (i.e. within 2-4 m of the limit). The last set, of borderline distances, will most often be empty.
With this approach you can get exact results with a query speed that is effectively the same as for a simple UTM distance calculation!
Terje
Oops! The less than sign before "maxDist*maxDist" was stripped away when I hit submit. :-(
Terje
If it is just a set of proximity queries, then you could almost do that with search&replace on your SQL code
I.e.if you can store coordinates in UTM distance calculations become dead simple:
"select * from hospitals where (lat-targetLat)*(lat-targetLat)+(lon-targetLon)*(lon-targetLon) maxDist*maxDist"
Working with degrees makes it a bit harder, but as long as maximum distances are within a few 100 km you can get away with a simple cos(targetLat*deg2rad) scaling of the longitude values.
Terje
Stay passionate!
I am 54, and I started to become passionate about programming in 1977, initially writing Fortran 2 on punched cards, then I went on to Simula, Pascal, assembler, C, etc, etc.
During the eighties and first half of the nineties I was probably best known as one of the better x86 asm programmers.
Since then I have never stopped programming, even though most of my professional career over the last 15-20 years have been involved with solving performance problems in other people's code and/or systems. I still frequent comp.lang.asm.x86 and comp.arch, discussing algorithms, optimization and computer architecture.
I do hope/believe that I could still get a new job if I wanted to move away from where I am.
Terje
In the PDF you'll see that the leap week they propose is based on the current Gregorian calendar
"Note: the “Extra-Week Years” are every year in which the Gregorian calendar begins or ends on a Thursday:
2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088,
2093, 2099, 2105, 2111, 2116, 2122, 2128, 2133, 2139, 2144, 2150, 2156, 2161, 2167 "
I.e. in order to use this calendar you would still have to maintain the current calendar in parallel, so you gain the "benefit" of having to work with two different calendar systems. :-(
Norway is even further north than Canada, we have _very_ little flat land at low elevations close to the ocean, and we get pretty much all our electricity from hydro-electric plants.
We will still get badly hurt by increasing global temperatures:
The first result of a temperature rise is a large increase in the amount of severe weather, something which you could argue have already started. In the US that means longer and much more severe tornado seasons, in Norway we get severe river flooding from melt water (both snow and glaciers) combined with heavy rain periods.
Yes, our agricultural growing season will increase, but with only 2.7% potentially arable land, this really doesn't make much difference.
Terje
Working with starting points less than 1e9 you can try 670617279 which leads to a sequence of 987 steps.
Starting with 319804831 gets you close to 64-bit overflow, with an intermediate value of 1414236446719942480.
Terje
Well, doing it for ALL values is what the mathematicians are trying to do, right?
I hope it was clear from my post that I meant "as many odd integers as possible"! :-)
Terje
I first heard about this conjecture many years ago (25?) and did what most geeks would do; I wrote a program to test all odd integer values and check that they did in fact reach 1.
The obvious approach is to remember the count for each value as you try them, then check any intermediate result against this table:
If found, just add that value to the current count and store the result.
This approach breaks down when you want to test starting values much larger than 2^32, because the space to store the table becomes larger than available memory.
One of the first optimizations is to realize that the result of taking 3n+1 starting from an odd (n) will always be even, so you can simply include the following n/2 (a shift) and increase the count, while getting rid of the multiplication by 3:
Odd(n):
n = 2m+1
3n+1 = 6m + 4
(3n+1)/2 = 3m + 2 = n + (n>>1) + 1
In asm this can be simplified to:
again: ;; Assume even, so divide by two and shift the bottom bit into carry ;; If the result of the shift was zero, we're done!
shr eax,1
jz done
inc edx ;; Increment number of steps ;; No carry means even input, so go back up
jnc again
inc edx ;; One extra increment ;; The starting value was odd, so now we need to multiply by 3 and add 2:
lea eax,[eax+eax*2+2]
jmp again
done:
A much more sophisticated step is to see that the next N operations are determined by the bottom N bits of the current value (as long as there are more than N bits available), basically allowing you to convert those N operations into a multiplication, an add and a shift right.
Next you realize that the intermediate values can very quickly overflow a 32-bit unsigned integer, and even using 64-bit values does not get you very far.
My approach back in those days was to use a variable number of 32-bit counters:
With a single counter I check for getting to 1 or overflowing so I need to use two counters.
With two (or more) counters I test for the top counter becoming zero, allowing me to reduce the number of counters, or for overflow forcing another incease.
All of this is of course much easier in asm than C,since you can use the ADD/ADC combination to perform arbitrary precision
Terje
Bollocks indeed:
a) Even with small amounts of hidden data (20 MB in 160 GB was quoted), you will still end up with an _extremely_ fragmented file system:
Each hidden bit requires either a sequential or fragmented block placement, which means that 20 MB needs 160 Mbit or 160 million frag/nofrag chaining decisions.
This works out to one such block per kB of disk space, but since the FAT32 filesystem normally uses 4 KB (or larger) clusters, you would have to decrease the block size to either 1 KB or 512 bytes (the sector size, so the minimum possible).
Since the (presumably compressed and encrypted) data to be hidden will have 50% 0 and 1 bits, the allocation run lengths in the file system will average just two clusters, this would be extremely obvious on any low-level scan of the file system.
I.e. you could make this system work, but only in order to hide a few KB of data, not MB!
Terje
A self-signed does need to result in a warning, and you really should not accept one from any serious company.
Having signed DNS records as well would make it much harder to run MITM attacks.
Terje
There are literally millions of web sites, like my own, that are based on a shared hosting provider, right?
This means that all the domains on a single server starts out by sharing a single IP address. This works perfectly well for HTTP, since the web server will see which domain the client is trying to communicate with, so it can respond with the proper set of pages.
For HTTPS otoh you need something more:
a) A signed (not self-signed!) SSL cert, which means that you have to hand over a not insignificant amount of cash every year or two, otherwise your server will cause strong warnings on every browser out there.
b) A dedicated IP address, since a standard SSL certificate is bound to a particular address.
Personally I am paying about $6-7 per month in total for 5+ domains hosted with Dreamhost, putting them all on HTTPS would make it maybe 10X more expensive.
The solution to (a) above is to make it much easier to accept self-signed certs in browsers, while (b) will be solved by ipv6.
Terje