I have never understood why it is not possible to log in to a web site using public key authentication (SSH key) just like you can if you were SSH’ing in via a shell.

For the average person, this would be irrelevant.

But for developers who need to access a control panel or administration area, it would be perfect.

Paging through content, one page at a time, waiting for it to load each time is labourious.

I want to be able to just keep scrolling.

When my scroll bar reaches the bottom of the current content I want to be able to detect that and then immediately download the next page of content.

Never understood why houses and offices are not built with arrays of inductive coils laid out in a cellular mesh and embedded directly in to the walls.

We could just have a normal electrical power socket with a suction cup on the back that you stick on the wall that draws power directly from the inductive mesh.

Boom!

Instant power socket where ever you need it.

You could embed the mesh directly into the dry wall and let it electrically isolate itself whenever it is cut.

The mesh layout would also be robust enough to route power around areas that have been cut.

If you made each portable, remote power socket addressable, i.e. with an IP address and a small microcontroller built in to it, you could directly control the power socket from a central system. Switch lights on and off, monitor power draw, and so on.

An idea I have been pondering recently is using very large data-sets as a means to compression. Two parties want to exchange large amounts of data over a very limited amount of bandwidth, they can’t agree up front what data will be exchanged in the future, but they can agree for now to both receiving two identical copies of a very large amount of data that is indexed using a sliding window with the index of each piece of data stored in a lookup table.

So now each party has a large lookup table of robust CRC’s or equivalent, and each CRC maps to a piece of data in the larger data set. Both parties go off to opposite sides of the world and connect over a slow connection to each other, when one party wants to transmit a sizable amount of data to the other party the first party would scan through they local copy of the large data set, looking for either identical data matches, recording the identical match index in to the data set, or “close enough” matches, recording the index and the differences. Then the first party could transmit these indices, or indices and differences to the other party.

It would also be possible to create this large data set either from a very large prime number or a sufficiently random, non-repeating, seedable sequence if both parties agree to the random number algorithm and seed in advnace.

Obiously if we are going to store this much data then hard drives need to come down in price. I’m thinking for this to be a valid experiment you would require at least 500GB, possibly even 1TB of data storage to test out this idea but it would be interesting to see.

With this technique it would be possible to transmit web pages or binary data across slow connections much faster than what is currently possible, though as bandwidth increases in the future the value of the idea becomes less important.

Trader Client Description

The Trader Client works on several layers. At the top layer is the User Interface, this is a separate thread that handles everything that the Trader wants to do such as downloading files, making Offers, etc. At the lowest level is the Command layer, handling all input from other Traders, the WhereHouse Server, etc. Anything below this level is considered network layer, and beyond the reach of the Trader Client.

Making a Request

When a Trader clicks “Download Request” the User Interface creates a Download object and sets it running. This Download object inserts Download Data Block commands in to a Download Stream, sends Commands to the WhereHouse Server to request Data Blocks. This Download Stream is intelligently managed by the Trader Client so that it does not flood the WhereHouse Server with requests. The Download Stream has a thread that monitors the number of active requests at the Server and the amount of available bandwidth, as bandwidth becomes available so the Download Stream will send instructions to the Command layer to retrieve data.

Downloading an Offer requires that the Trader Client look in its database of Offers, retrieve the number of blocks that make up that Offer, and place an appropriate number of Request Data Block commands in to the Download Stream. An entry is added to the User Interface to signify that the Trade has been queued, this Trade may be removed from the queue at any time. To do this the Trader Client must clean up the Download Stream, close any active Transfers for that Trade and inform the WhereHouse Server to purge all Request Data Block commands from it’s own queue. The Trader Client expects an “OK” response from this purge command.

When the WhereHouse Server responds to a Request Data Block command it will send the Trader Client a Request Data Block ID, an Trader IP Address, a Cache Block ID and an MD5 checksum. To retrieve the Data Block the Trader Client must connect to the supplied IP address, send a Request Cache Block command along with the Request Data Block ID and the Cache Block ID. It will receive a Response Code of one of the following:
a) OK – the Response Code also contains a single Data Block (4KB of data) as a parameter
b) Request Data Block ID Invalid/Expired – the request is invalid or expired
c) Cache Block ID Invalid – a Cache Block was asked for that does not exist
d) Trader IP Invalid – the incoming trader’s IP address does not match the expected IP address

Once the transfer of data is complete the Trader Client should disconnect from the other Trader.

Once the Data Block is transferred the Trader Client should disconnect from the other Trader and the connection closed. The Trader Client should calculate a 128-bit MD5 checksum for the 4KB of data to ensure it’s integrity. This calculated checksum is compared against that supplied by the WhereHouse Server when the Request Data Block command was responded too. If they match then the data is good and can be placed on the hard drive for later shuffling. If the checksum is bad then the Data Block must be thrown away and a Request Data Block command for that Data Block placed in to the Download Stream again.

The Trader Client at the end of the MD5 calculation should send a Complete Data Block command to the WhereHouse Server that indicates whether the MD5 matches. If the Trader Client failed to receive all of the data, or if the connection was prematurely terminated, or if the Trader’s request for a Data Block was refused for any reason, or was unable to connect, the Trader Client should inform the WhereHouse Server with appropriate parameters. Three of the parameters that are sent to the WhereHouse Server with this Complete Data Block command are the Request Data Block ID, the Trader IP Address, and the Cache Block ID that the Trader Client originally received. The Server will use these items to monitor the network. Another parameter is how long the transfer took from when the Request Cache Block command was sent to the other Trader to when the connection was closed, in milliseconds. This is used by the Server to handle network statistics and Fair Trading parameters for each Trader.

The reason to use this mechanism is to prevent Traders just making a single request to the WhereHouse Server for a data block and then constantly connecting to another Trader to retrieve all Data Blocks from that location.

Request Data Block command (to server)
Request Cache Block command (to another Trader)
Request Data Block ID
Trader IP Address
Cache Block ID
Data Block (item)
Cache Block (item)

A brief description of Multi-Pass and how it works

There is general inefficiency on the Internet for trading files so I’m proposing a new standard to replace the impromtu warez ftp sites, the web pages full of links that never work, and bots on IRC that have a minimum speed requirement or are always busy serving up everybody else’s requests but never yours, and they can never resume their transfer on a 50MB download.

Here’s the low down. I’ll describe the client side first, and then the server side.

“Trader” Client Side
A client is known as a Trader. Trader’s have a client side program that connects to a central WhereHouse Server, similar to IRC, the WhereHouse Server handles a bulletin board system of messages and location data. The bulletin board allows people to post requests, answer requests, and have general threaded conversations, but it is not intended as a chat network. When the Trader Client first connects it registers the Trader’s name. Other info is also sent to the WhereHouse Server to let it know what kind of connection the client is using, and the resources available for the WhereHouse Server to use.

The client receives a list of Trades from the WhereHouse Server that specify what other people are making available.

Trades & Offers
A Trader can tell the WhereHouse Server that they have Offers available, a Trader may have more than one Offer available. An Offer may be made up of multiple files totalling many hundreds of megabytes. The Trader client automatically breaks each offer in to a number of fixed size blocks, calculates a 128-bit MD5 for each block and sends this list of MD5’s, along with a brief description of the Offer, a small bitmap for any group affiliation and a file_id.diz from the Offer (if one is available) to the WhereHouse Server. The WhereHouse Server then distributes this information to all other Trader’s currently connected.

Making an Offer

To be filled in

Requesting a Trade
A Trader can retrieve an Offer and sends a request to the WhereHouse Server asking for a block from the request. A Trader’s request may only contain a request for a single block, but multiple requests can be made immediately after each other. Though it is advised that the Trader client does not send more than 20 or so simultaneous requests to prevent burdening the WhereHouse Server. As a request is responded to another should be sent to the WhereHouse Server immediately. A request may not be responded to immediately. It is placed in to a list for that Offer, and when an available slot opens the WhereHouse Server informs the Trader client that it may proceed to download. When a Request Acknowledgement is received it contains an MD5 crc for the block requested, an IP address that the block may be retrieved from, and a Request Location ID.

The Trader client, upon receipt of a Request Location ID should open up a TCP/IP connection to the Request Location IP, wait for a “Please send Request Location ID” command from that IP, and then send it’s Request Location ID. This Request Location ID is good for the transfer of a single block of data, usually about 4KB. Once this block is retrieved the Trader client should close the TCP/IP connection, calculate the MD5 crc for the retrieved block, and inform the WhereHouse Server if it was the Request MD5 matched the calculated CRC, or whether it failed. If the CRC check failed the Trader client should re-issue the request for that block again, otherwise if should issue a request for the next block, if any more are remaining to be retrieved. Once an Offer has been completely retrieved it must be “shuffled” in to it’s correct order as requested blocks of data will be received out of order. This shuffling may take place during transfer of the entire Offer, but the data must be shuffled in to it’s correct order.

When a requested block of data is retrieved, it is also placed into a cache, this cache is user definable in size, but the more the Trader caches, the more generous the WhereHouse Server will be in answering requests for data.

Once a block is cached, the Trader client must inform the WhereHouse Server that the block is being cached.

Visitors & Visitor Centre
A Trader client can receive a command of “Incoming Cache Request” from the WhereHouse Server, this command will contain an IP address, a Request Location ID, and a Cache Block ID, this cache request will be from another Trader, the Trader should listen for an incoming connection, when it connects it should send a “Please send Request Location ID” command to the Trader. When the Trader responds, it will send a Request Location, and a Cache Block ID. The IP of theTrader, the Request Location ID, and the Cache Block ID should all match those that the WhereHouse Server sent. If they do not then the connection is refused, and the WhereHouse Server is informed.

If a Trader client ever receives a “Cache Request Denied” from another Trader it should inform the WhereHouse Server that it’s request was denied. If a Trader is ever unable to connect to another Trader for a Cache Request it should inform the WhereHouse Server that it failed to connect. If a Trader’s connection times out while downloading from another Trader it should inform the WhereHouse Server.

A Trader can also withdraw their Offers from the WhereHouse Server, these Offers then become unavailable, and all cached blocks for that Offer being held by other Traders also become invalid.

When a Trader connects to the WhereHouse Server it informs the WhereHouse Server how much bandwidth it is offering, and how much cache space it is offering. This influences how quickly the WhereHouse Server will respond to Requests. A Trader may not offer more bandwidth than they are actually capable of handling. The WhereHouse Server keeps statistics on each Trader and it is only after a Trader has been connected and handled several Requests for Cached Blocks of data that the WhereHouse Server will “trust” the Trader client enough to give it a Request status equal to it’s “announced” bandwidth.

The cache is broken up in to 64KB chunks, each 64KB represents a single Data block, all transfers of an Offer takes place in 64KB chunks. There may be several 64KB transfers of a single Offer going on at once for a single Trader. A Trader may also have several Offers downloading at once. Each Block Request runs in its own thread, a thread handles each Offer, and a central thread handles all Offer transfers and coordinates the shuffling of data.

Every Trader that connects to request a cached data block receives a single thread of their own, and a central thread for that handles all incoming connections and disconnections.

A Trader can offer “pre-cache” ability. This indicates that they are willing to request and cache data blocks for parts of Offers that they are not personally requesting. This allows the WhereHouse Server to intelligently manage cached blocks and relieve the burden on both very popular Offers and also not so popular Offers. A Trader client’s cache is managed on the “least requested, least accessed” principal, when the cache becomes full and room must be made for newer, or more popular blocks, the list is sorted in to the least accessed blocks first, and then sub-sorted in to oldest first, then the blocks at the top of the list are removed. Cached blocks expire after a period of time that the WhereHouse Server sets, the WhereHouse Server will inform the Trader client when to expire blocks, either because the Offer was withdrawn, the Trader making the Offer has disconnected, or the block is considered invalid because it is “old” and it may not be actually valid anymore.

When a Trader client sends a command to the WhereHouse Server it generates a unique 128 bit Command ID, the WhereHouse Server will use this Command ID when replying, so that the Trader client knows what the reply is referring to. As the commands and replies happen asynchronously there may be multiple outstanding commands that the Trader has sent to the WhereHouse Server that are awaiting a response, and similarly the WhereHouse Server may have sent multiple commands to the client which may be waiting for attention, or further input. A command expires after 120 seconds, if either the Trader client or the WhereHouse Server fails to respond to a command in this time, it expires and the command goes unanswered. Depending on the particular command will depend on the action taken. There is one exception to this, a Request Data Block command to the WhereHouse Server from a Trader client. This command has a time-out that is set by the WhereHouse Server but will usually be anything up to half-an-hour, and usually never less than ten minutes. For a popular Offer there may not be enough Cached Data available on all the Traders for a response to come back immediately.

A Trader Client will not acknowledge a Expect Connection command from the WhereHouse Server until it is sure it can handle the transfer. If current outbound throughput for all transfers to other Traders is greater than 90% of maximum bandwidth then the command goes unanswered. Should the command sit idle for more than 60 seconds then the Trader Client informs the WhereHouse Server that the command is “refused due to insufficient bandwidth”.

When a Trader disconnects from the WhereHouse Server and then reconnects at a later time, it’s cache is invalid, it needs to validate the cache with the WhereHouse Server and purge any blocks that are invalid. The Trader sends commands to the WhereHouse Server for each Cache Block it has, along with it’s unique Cache Block ID, the WhereHouse Server will return a valid/invalid response and the Cache Block can be either removed or kept. It is assumed that if the Cache Block ID is valid according to the WhereHouse, that the Trader will be keeping the Cache Block.

WhereHouse Server
The WhereHouse Server listens for incoming connections from Trader Clients, when a connection arrives it hands off to a separate thread that will handle that Trader exclusively (this may not be that efficient and should be looked in to). The WhereHouse Server sends a command to the Trader Client requesting that they send their preferences and resource availability. The WhereHouse Server maintains a list of Traders that are connected, Offers that those Traders are making available, a list of Cache Blocks pertaining to each Offer, where those Cache Blocks are located, their MD5 CRC numbers, and statistics on each Offer, including a brief description, a file_id.diz, and a bitmap for a group affiliation logo. A Trader can make an Offer and the WhereHouse Server will receive a list of CRC numbers for each block that comprises that Offer, including some other information.

When a Trader makes a Request Data Block, the WhereHouse Server will place this in a list of Pending Requests, sorted on a priority base that results from the resources that the Trader is offering. The more resources a Trader offers, the higher the priority that they are given, and therefore, close to the front of the queue when a request is made. A Trader offering a full T3 and 10GB of cache will be right at the front of a queue compared to someone offering a 28.8Kb modem with 1MB of cache.

If a Trader has announced that they will pre-cache data they are sent commands by the WhereHouse Server to request particular blocks from other Traders.

Should a Trader disconnect from the WhereHouse Server the list of blocks that they were caching is invalidated, and removed from the WhereHouse Server’s list of known blocks. Any Offers that they made available is also removed, all connected Trader’s are informed that these Offers should be removed from their lists, and the Server will also send commands to any Traders that were caching those Data Blocks that related to the Offers to invalidate them and remove them from the cache.

The WhereHouse Server keeps a list of Pending Requests, it also keeps a list of Available Resources, Resources are basically an amount of bandwidth that each Trader is making available. When a Request is in the queue that matches a cached block, and that cached block has resource available for transfer, ie, there is a Trader that can handle the connection, the WhereHouse Server sends an Expect Connectionb command to the Trader. This command will have an attached IP address of the Trader who will be connecting, a Request Data Block ID, and a Cache Block ID. When the Trader responds to this command, the Server then sends a command to the Trader making the Request with the IP address of where the data block is cached, the Request Data Block ID, and a Cache Block ID, and an MD5 CRC for that data block. The response to this command will be received once the data block has been transferred by the Trader Client. The response may be “OK” or “FAILED” and a reason for failure, such as incorrect CRC match. The Trader Client will also send the WhereHouse Server the statistics for the transfer, ie, the length of time it took to transfer the actual data. This way the Server can keep track of bandwidth usage and also whether a Trader Client that announces their bandwidth capability actually has what they say they have.

Once several transfers from a particular Trader have taken place, the WhereHouse Server will upgrade their status, or downgrade it, depending on network performance. If network performance falls below announced levels for that Trader then their status is downgraded. Announced Performance is equivalent to 100% efficiency from that Trader and they should be trusted, anything below will mean that the trader loses status in their list to handle requests. Also the server will need this information for knowing when that Trader client can handle another request.

Should a Trader Client disconnect the WhereHouse Server needs to remove from it’s cache data block list any blocks that were held by that Trader Client.

Visitor Centre
Trader
MD5
WhereHouse Server
Trade
Offer
Request
Command
Acknowledge

Why do laptops need so many cables?

When I put my laptop on the desk I have to connect USB, power, network (if I want to access files on the server at high speed).

If I want an external keyboard, mouse or monitor, there’s even more cables.

Then there is firewire too.

Okay, so I know docking stations are available.

But they are generally expensive, cumbersome, inconvenient, specific to one particular make & model of laptop.

And you generally only ever have one of them, usually at the office.

So I’d need two or three for my laptop to suit my needs.

Why not integrate everything you need into the PSU, a mini docking station effectively, that connects to the laptop via a single cable?

You’d need to plug all of the cables in to the PSU. But a PSU is generally cheap, small, available from 3rd parties, not inconvenient to carry, does not take up much desk space when not being used.

I look forward to a day when a single serial cable, perhaps some future version of USB, can carry power, video, audio, network and external storage data traffic.

Come on Apple, get on that, would you?

You know the first thing I’m going to buy when I have enough money?

A driver.

It’s not that I dislike driving, I just do not want to have to drive if I don’t have to.

I want a chauffer, not so that I can be self-important or because I have so many places I need to be chauffeured to and from, but so that I can get on with work, or read, or write, without the drudgery of actually have to drive myself from one place to the next. It’s not laziness either. Driving, like many activities, is a complete waste of time for most of the time.

But right now, I don’t have the funds, so how about considering other options?

Bus? Train? Taxi? Public transport is too inconvenient and too slow and requires too much thinking. Taxis are too costly and still inconvenient.

No, what I want, is the ability to walk out of my door, the car is there, ready to go, I hop it, I go places. I need a chauffeur.

Failing that, I need a self-driving car. Completely automatic. I hop in, I tell the car verbally where I want to go, e.g. “Nearest McDonald’s” or “Take me to work” or “Take me home” and the car knows where to go, instantly starts up, calculates the route, and off we go in comfort and safety and all to arrive in a timely fashion.

And I think I’ve figured out how to get one.

I see a vast network of people driving cars all day long across the streets and freeways of Los Angeles. But these drivers, these people at the steering wheel of the car, they’re not actually in Los Angeles.

Here’s how to achieve the self-driving cars of the future.

We outsource the driving.

With GPS, cellular networks, a couple of cameras for vision, and some very simple software, someone sat at a cheap computer terminal in a remote part of the world, earning far less per day than me, can be paid a reasonable sum of money to drive a car from point A to point B. And the great thing is, once they’ve finished the driving, the driver is ready to remotely operate someone else’s car in some other part of the world. I see vast cubicle farms of people remotely piloting vehicles all over the world.

No clever artificial intelligence, no worries about recognising objects in the road, completely self-driving, self-parking, voice activated vehicles that cost just a dollar or so per day to operate. Would you pay a dollar, less than a cup of fancy coffee, to have someone drive you to and from the office whilst you relax and read the paper?

We’re outsourcing so much other stuff, why not do the same with driving?

I see a day, possibly two or three decades from now, when all street lighting is LED based, controlled remotely via a wireless signal from a central location, and mostly self-powered.

Power for the lights will come from a battery bank, backed up by the main power grid. The battery for each street lamp will be charged by a vertical wind turbines mounted on the light poles and a small, solar array attached to the top of the pole.

Each LED street lamp transmits a signal back to a central control system that monitors battery level, battery health, and whether the LED lights need any maintenance.

Each street lamp can also monitor its own light output via a photo receptor that will detect when the LED itself fails, so that a maintenance crew can be scheduled to come out an repair it.

I don’t expect to see street lighting like this until 2020 or even 2030 at the earliest.

With the price point of LED lighting falling rapidly, the far lower energy requirements of LEDs, and the ability to produce natural white light at reasonably high lumens, I wonder how long it will be before we start switching all of our street lighting on roads, motorways and other areas to LED installations.

With the advent of self-driving cars, we will see entire urban areas moving towards more pedestrianised streets.

Houses will no longer have garages dedicated to storing these rapidly depreciating “assets” that are parked for more than 95% of their usable lifespan.

Neighbourhoods with high a Walkability Index will become desirable.

Houses that already have garages will be converted into offices or extra living space.

Just because something seems normal right now, doesn’t mean it will be normal in 50 years.

The proposal is to use solar bodies, such as large planets, to bounce radio signals off of, as a means of high capacity, high latency data storage.

The digital data is converted in to a radio signal and transmitted from an Earth-based station at another planetary body, e.g. Neptune, which is around four hours away at the speed of light, so round-trip time would be about eight hours. A second receiving station would receive the radio signal, convert it back in to an error corrected digital form, hand the data off to transmitting station which would then send the signal back to an Earth-bound receiver, which would then perform the same steps as the remote receiver, and the entire cycle would repeat, the data endlessly bouncing back and forth between Earth and a remote transceiver.

The amount of data that can be placed in to the storage buffer is orders of magnitude larger than anything that we could hold on Earth. A radio signal can easily pack several megabits in to a single pulse traveling at the speed of light. Before your transmitted signal has reached the receiving station you can begin transmitting again. As the circular data buffer fills up so the pulses become longer until it is a continuous signal.

You wouldn’t need to build and complete the remote receiver at the final destination to make this system work either. You could construct your remote transceiver in near Earth orbit, then tow it out to the desired location, so long as you keep the transceiver powered up and firmly fixed in the path of the signal, it can be operational with data capacity (and latency) increasing the further it moves away from Earth.

Problems with this approach: High latency accessing any one piece of data. Error correction. Planetary bodies being eclipsed by large objects transiting across their orbit. Planetary bodies suddenly exploding with a vast shockwave due to excessive mining with nuclear devices.

What we need is an aerosol or spray bottle that contains a spray that will dissolve or liquefy feces on contact.

When you take the huge poop in the toilet and it won’t flush down.

Or it is so sticky it glues itself to the side of the toilet bowl and leaves an ugly black lump behind that refuses to flush.

A quick spray.

*pst* *pst*

And that lump gets dissolved away and can be flushed.

I do not understand why computer keyboards do not have braille markers on each key.

Not so that blind people can type, but so that sighted people will, just by dint of time elapsed and common usage, learn braille.

Have been tinkering with self-healing plastics and vinyls lately.

I can puncture this stuff with a dart, and it immediately repairs itself when you take the dart out. I think it is physically possible to create an inflatable dartboard.

The only downside is that the inflated portion will deflate ever so slightly every time a dart pierces it.

I don’t know why we would want this, but it seems like a good idea.

Your own farts smell good to you.

The farts of another person do not.

The odour from farts are caused by the bacteria in your body digesting the food you consume.

Theory: Your body enjoys the smell of its own bacteria but not the smell of the bacteria in other people’s bodies.

It is possible that the bacteria of your immediate family members have some bearing on whether you find them palatable.

It is highly likely that the bacteria in your Mother’s body is more pleasant to you, especially at an early age, than any other family member.

Two people in a close intimate relationship may eventually exchange enough bacteria, or become used to the bacteria, that they no longer find each other’s farts offensive.

I suspect when the majority of vehicles on the road are self-driving and proven highly reliable that many people will no longer have driver’s licences as we understand them.

A person might hold a simplified license, much like people who are licensed to drive an automatic car (automatic gears) but not a manual car (manual gear shifter), or a motorcycle licence versus a car licence versus a heavy goods vehicle licence.

Having a licence to operate a vehicle will be reserved for professionals, people who like to drive for pleasure, and enthusiasts.

If an orbiting space station is built with extended arms that have a diameter of approximately 1 A.U. and then rotated at slow velocity the objects at the arms extremities will rotate faster than objects at the hub. The structure doesn’t need to be 1 A.U. (about 93,000,000 miles) but it’s a good size, it could be made one Earth diameter or even the distance between the Earth and the Moon, approximately 200,000 miles.

Obvious problems are getting enough material to build the arms, stress on the arms as they rotate, and finding enough space where you aren’t going to wipe out a major civilisation. But really, these are minor problems and don’t require any sort of exotic materials or special technology we don’t already have.

It will be interesting to observe the exhibit-able properties.

First, a small time dilation effect will be observable between the hub and the arm’s extremity.

Second, the biggest problem I foresee though, and one I am not sure how to figure out the effects of, is that the ends of the rotating arms will really be moving quite fast in relation to other parts of the structure.

What will that do to electrical wiring?

To the physical properties of the material that makes up the structure?

If one part of the structure is undergoing a time dilation effect, however minor, what will that do to the overall structure?

You have the paradox that certain parts of the structure will be older (or younger) than other parts of the structure?

You will also have the paradox that someone sat at the exact centre of the structure looking out along one of the arms will see the arm bending and trailing behind.

In fact, eventually someone looking from the centre down one of the arms should see the arm either disappear or detach itself from the structure due to the frame of reference getting further and further out of synchronization.

With a structure 1 A.U. in length, rotating at 1 revolution per hour, the rotational speed at the extremity would be equal to the circumference of the structure as it rotates. So 93,000,000 * PI This means that the rotational speed would be 292,168,116 miles per hour.

The speed of light in a vacuum is about 186,000 miles per second, or 669,600,000 miles per hour.

So the rotational speed of the arm would at the ends would be close to 43% of the speed of light.

At that speed the ends of the arms may require some sort of shielding to protect them from collisions with space dust, micro-meteorites, etc.

Interestingly if you think about it, isn’t the Earth itself undergoing some sort of effect such as this? A person on the equator is travelling faster, and hence undergoing a different frame of reference, to an observer at the North Pole.

Is this an inherent property built-in to relativistic physics that a single chunk of matter, i.e. the Earth, cannot undergo relativistic changes, or is it due to the mass of the Earth and the effects of gravity warping space-time?

Interestingly this structure would not necessarily be required to be rigid. It could be made out of a very strong “rope” (for want of a better word) and spun like a bolas. The center motion of a bolas does not appear to be a rotation of a constant fixed axis but appears, from observation, to describe an ellipse and is more of a circular back and forth motion very similar to how female breasts move in an elliptical orbit when a woman runs.

Any objects at the end of the structure could be sling-shotted in to space at extremely high velocities.

Or they could be sling-shotted at planets too, a 1,000lb weight travelling at a significant portion of c would impart enough energy to obliterate a major metropolitan area such as London. Though the calculations for the orbital mechanics may be beyond us at this time, thank goodness.

Self-driving cars are going to happen.

It is simply a matter of time.

Maybe 30 years from today for the first vehicles that are partially automated, that is, they can drive safely on private roads or roads that require a permit such as a motorway where the traffic is more predictable.

Perhaps 40 years from today for a significant number of self-driving, self-navigating vehicles on the roads.

And 50 years from today (at the outside) for almost all vehicles to be self-driving.

In 50 years vehicles that are non-self-driving will be an anomaly.

In a national disaster relief effort should we prioritze taking blood from fat people more than thin people?

Technically fat people have more blood to give.

Someone who weighs 300lb vs 150lb would have 150ml of extra blood sloshing around in them.

Think of it, in a national disaster we would mobilize (though slowly, and with a lot of sweating, and puffing and swearing) an army of obese individuals to rapidly contribute to the national blood supply.

I am not saying my logic isn’t flawed, but it is an interesting mental exercise.

        .;''-. 
      .' |    `._ 
     /`  ;       `'. 
  ,'\|    `|        | 
  | -'_     \ `'.__,J 
 |      `"-.___ ,' 
 '-,           / 
 }      __.--'L 
 ;   _,-  _.-"`\         ___ 
 `7-;"   '  _,,--._  ,-'`__ `. 
  |/      ,'-     .7'.-"--.7 |      _.-' 
  ;     ,'      .' .'   -. \/     .' 
    \ |      .' /  |    \_)-  '/   _.-'`` 
     _,.--../ .'     \_) '`_    \'` 
   '`f-'``'.`\;;'    ''`  '-`    | 
      \`.__. ;;;,   )            / 
        / /<_;;;;'   `-._    _,-' 
       | '- /;;;;;,      `t'` \ 
       `'-'`_.|,';;;,      '._/| 
        _.-'  \ |;;;;;    `-._/ 
             / `;\ |;;;,  `" 
           .'     `'`\;;, / 
          '           ;;;'| 
              .--.    ;.:`\    _.--, 
             |    `'./;' _ '_.'     | 
              \_     `    `)       / 

We know the upper limit on the speed of light in a vacuum, we refer to this as “c”. About 186,000 miles per second.

Does time itself have an upper limit on how fast it can go?

We know that time slows down in a gravitational field. If that is so, then time on the Moon. The Moon has a weaker gravitational field than the Earth, and also sits at the edge of the Earth’s gravitational field, therefore time on the Moon must run faster than on Earth.

If we move further away from the planet’s and the Sun, and out in to deep, deep space, between the inky blackness between the stars, time must therefore speed up even more.

Time slows down in a gravitational field. Time has to speed up due to the lack of a gravitational field.

How fast can time flow? What is the upper bound? Light has an upper bound. Does time?

 

Assume the universe is a big computer simulation.

Assume that any intelligent, self-aware inhabitants of the simulation are capable, at some point, of creating a simulation of the universe populated by intelligent, self-aware inhabitants.

So where in the chain of simulations do you stop?

Going in either direction?

This is the “turtles all the way down” argument.

In a moment of boredom I was thinking about mass and gravity and pondered the possibility that time is a function of mass. i.e. time cannot exist without mass. Gravity is a function of mass, so why not time. I guess I should go and research this and I am sure someone has already thought about this question years before me (as they usually do.)

If only two objects exist in the universe, both very distant from each other. They will exert, however minute, a gravitational force on each other.

Time, from an outside observer’s point of view, slows down for any object as it approaches a massive object, until time effectively comes to rest for the observed object. It is reasonable to assume that time will “speed up” as the objects move away from each other. For the massive object, from an outside observer’s point of view, this would be an almost imperceptible increase, but for a smaller object moving away from a massive object, the increase in the rate of time would be dramatic. It must be assumed that “time” is faster the further away the objects are from each other. At an infinite distance time MUST “speed up” to infinity. In the absence of mass, time could not exist just as gravity cannot.

Because fat people carry more blood (an extra fluid ounce of blood for every extra pound of fat according to an encyclopaedia) it would be for the national good for people with extremely rare blood types to be morbidly obese, because they would have more blood they could spare.

I am not saying my logic isn’t flawed, but certainly amusing to think about.

Forgive me for this indulgence. I was eight and a half years old when I wrote the notes below. Just typed it up from some very old notebooks. Even back then I had some weird thoughts.

So if I take some jelly and I push against it, it deforms and let’s say it’s a large square block of jelly. So if I push on one end, my finger sort of distorts the jelly which makes the other end of the jelly distort and jelly bulges out in various places. But the jelly at the far end furthest away from where my finger is pushing doesn’t distort as much because the jelly near my finger bulges outwards around it.

Also if you think about it in that case as jelly moves back and forth, jelly is just made of the same stuff that everything else is made of, metal & steel, and wood & trees and things like that.

So the far end of the jelly moves after my finger pushes, like if I drop a stone in to a pond the waves ripple out across the surface of the pond and the amount if I have very large stone, if I have a bucket of water and a very large stone and I put the stone in a bucket of water, the water level in the bucket goes up, it moves up, it rises. Meaning that the stone is displacing (is that a word?) water. If I put my finger in to jelly, my finger is displacing jelly and a stone in a bucket doesn’t displace the water instantly, just like the ripples on a pond do not happen instantly.

They travel through the water at a limited speed. This means that if I put my finger in water the amount of water on the other side of the pond also moves but by a tiny, tiny amount. And water closer to my finger moves more.

With jelly it’s the same thing, if I push my finger in to jelly, the jelly that’s closer to my finger moves more than the jelly that’s further away from my finger. I guess we can call that absorbance? Absorbing? Whatever.

But the jelly that’s furthest away from my finger also moves, but by a tiny amount but it has to move after my finger has pushed in to it.

So I have a long plank of wood, it’s made of the same basic stuff as jelly. When I push on the end of a plank of wood, this plank of wood on the workbench, and I push one end with my finger, the plank of wood moves, but the wood close to my finger is being displaced because the wood, the fibers that make it up are more rigid than the jelly, they don’t move as much, but they still have to move.

My finger is applying, what do you call it, pressure or force? What’s the difference? If there for the wood works the same way as the jelly and the water, there is a wave traveling through the plank and the wood fibers at the other end of the plank furthest away from my finger move after the wood fibers that are closest to my finger.

I’m going to assume that the more rigid a substance, jelly or wood or steel, the faster that the force of my finger moves through it. So I can actually see in a large piece of jelly when my finger is pushing against one side seeing the other side deform after my finger begins pushing. But in a piece of wood I can’t see that because it has to happen too fast.

So if I now have a steel bar that I’ve got here on the work bench and I push one end, the steel bar is harder to bend or shape than wood, which means to me that I believe that the stuff that the steel bar is made of, the metal, is more rigid than the wood fibers that are in a plank of wood, which are more rigid than the jelly stuff in a block of jelly which is more rigid than the water droplets in a pond.

If that’s the case then if there was a material like a really, really strong piece of metal or something that was completely rigid, when I push on one end, the other end would move instantly, the wave, and I have to assume there is a wave passing through the wood and I have to assume there is a wave passing through the metal just like there is a wave passing through the water, the wave would travel instantly from where my finger pushes on it to the other end.

And if you have this completely rigid piece of metal you transmit a message faster than you could see. Faster than light maybe?

Hmm.

Sounds plausible but I suspect that the universe will conspire to prevent me from doing something like that. I suspect that the stuff that makes up wood and metal and rock, that there’s no completely rigid thing, substance anywhere in the world that would allow that to happen.

So what is the difference between pressure and force?