Posts by Vic 5860 publicly visible posts • joined 7 Dec 2007
Set up a scheduled task on one of their Internet facing computers which polls www.ipchicken.com, www.whatsmyip.com, or similar, scrapes the address shown, and emails it to you
I've done something a little simpler in the past...
Set up a scheduled job to do a wget http://myserver.example.com/their_name . Discard any return.
Then you just need to look in the Apache logs to find their current IP address :-)
Vic.
Legally speaking quite possibly none. All the services mentioned could very well be used out of the box to build a backbone on which they could run their own proprietary code without modifying any copyleft licensed code at all, thereby avoiding the legal need to contribute code back to the community.
Please stop repeating this nonsense. It is as false on the tenth reading as it was opn the first.
The GPL is available at http://www.gnu.org/licenses/gpl-2.0.html . Section 3 states :-
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the followinga) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
You will note that this doesn't say "only if you modified it" or anything like that; for a commercial redistribution of GPL code - as is the case with Tesla - the source is required either to be shipped with the binary or to be made available to any third party on request. And the written offer must accompany the code.
Vic.
As long as they're shipping stock Ubuntu plus ordinary user-mode binaries, they aren't shipping any derived GPL code at al
Bullshit. If they're shipping stock Ubuntu, they're shipping *loads* of GPL code. A significant amount of all GNU/Linux distributions is GPL, and Ubuntu is no exception.
The OS is Ubuntu's distribution, get yours through the usual channels
You appear to misunderstand the GPL. If Tesla is redistributing Ubuntu code, it needs to supply source. That's it. It doesn't matter that it's the same source as Ubuntu ships - Tesla still needs to supply that source on demand or with the binaries to remain GPL-compliant.
The proprietary user-mode binaries are merely aggregated.
Nobody's worried about any putative proprietary binaries. Tesla is shipping GPL code, so they need to ship source.
Yes, if they have made changes to the kernel or to any of the GPL'ed programs in Ubuntu, they have to make source of those changes available.
NO!
If they are shipping GPL binaries they need to ship source, regardless of whether or not they have changed them. Please *read* the GPL before making such erroneous statements.
Vic.
> I'd guess none, honestly.
You'd guess wrong.
If Tesla is shipping GPL code, it must *either* accompany every binary with the corresponding source *or* it must make a binding promise, valid for at least 3 years, to ship that source to any third party on request.
Given that the car is capable of OTA updates, it is incredibly unlikely that they are shipping source with every binary.
> there'll be nothing they've customized
This is irrelevant. The GPL requires you to ship the complete source for all GPL items within your distribution, not just your own patches.
> Whatever UI these are running is probably custom and not required to be open source
But if it *derives* from GPL code, it becomes covered in totop by the GPL. It remains to be seen whether or not it does...
> Do they have GPL disclaimers in the manual?
Back in 2012, they had no mention of the GPL in the manual at all. This is actually a violation, but the sort of thing that gets sorted out quite easily. But Tesla doesn't currently seem to be trying to sort it out, and that way lies a big problem.
Oh - and it's not a "disclaimer"...
Vic.
If I remember rightly the Linux kernel makes use of numerous microsoft patents, but is protected by a cross licensing deal of some variety
You do not remember rightly.
Microsoft keeps *claiming* that hte Linux kernel violates a large number of its patents. But they have refused to let on which ones.
The commuinity as a whole believes them to be FUDding. There is no evidence to refute such a position.
Vic.
As opposed to the sort of numpties who build servers with a RAID0 system partition.
I saw one of those at the last place I worked. On that server was a Wiki containing the only real documentation for one of the products they sell.
I got called in after the first-line guy had the brilliant idea of re-formatting one of the drives to get around the disk crash...
Vic.
If you code the scripts right, the difference would be negligible, down to a few milliseconds
This is not true.
SysV is inherently synchronous. systemd is not.
systemd will therefore start a box much more quickly, but at the cost of greater complexity, because it runs the start-up in parallel.
adding an ampersand in the end of the daemon invocation incantation in the Apache and Samba initscripts actually sped my boot speed up by a factor of five back in the SysV days.
But at what cost?
SysV scripts expect all previous scripts to be finished before they start. If you're forking off into the background, this expectation is no longer met. Thus, if you have a dependency between two scripts, you have just built a race hazard into your boot system. This is not a good way to build reliable systems.
You gotta fork the initscript to the background
You must not fork the initscript into the background unless you're prepared to have boot-time failures. The minute or so you might gain simply does not warrant that sort of instability.
Vic.
> Many programs look at /proc/cmdline
That they *do* doesn't mean that they *should*....
> See "grep cmdline /etc/init.d/*" for some examples.
On my current laptop, I've just got livesys and livesys-late that do (and I don't really get what they're doing there anyway - probably an artefact of installing form a Live image). On my server upstairs, there are no /etc/init.d/ files that look at /proc/cmdline.
I agree with the earliler poster - these are command-line arguments to the kernel, and were already defined in that context long before things like systemd came along. Should a userspace program *decide* to look at the kernel's parameters and act upon them, on its own head be it; it is the one that is overloading those parameters.
Vic.
> just saying 'you're wrong' repeatedly doesn't advance the debate.
I quoted the bit you got wrong. Feel free to go back and look at it. If you can't work out why it's wrong - I suggest you read a grammar. It really ought to scream at you...
> likewise your inability to read my prior post disclaiming exactly this.
Oh., I read that post - as well as the other one where you claimed exactly what you disclaimed :-
I do have the strong innate understanding that allows me to use english as well as, or better than, many.
That's the nice thing about the written word - it tends to leave a trace...
Vic.
> It seems some people are really struggling to get what I say
We're not - it's just that what you say is wrong.
Many people are wrong much of the time - and that's just fine. But you set yourself up as being some sort of expert, whereas your knowledge of language is actually insufficiently thorough even to understand how wrong you are. So you get called on it...
Vic.
> It's mine by use, as it is yours by use.
It is neither mine nor yours byu use. It only holds value when everyone agrees on what sounds or markings actually mean. Thus your attempt to use it in ways other than the accepted norm serve only to devalue the language and demonstrate your own lack of capability. "I does it different like" is utter bullshit.
> A disagreement between us does not necessarily comprise a ballsup on my part
Indeed it does not - but your hopeless grammar certainly demonstrates a lack of that "innate" understanding you claim to have.
Vic.
> My language
Yours? Got a receipt?
> all the while ignoring its larger point I'm making.
When presenting oneself as some sort of linguistic expert, it would almost certainly be better not to have made quite such a ballsup of said expertise...
Vic.
> Go back to SysV init.
But ... but ... but ...
Then no-one could do any of that oh-so-important wily-waving about fast boot times.
Because, as we all know, boot time is *critical* to everything.
[vic@hobgoblin ~]$ uptime
13:20:55 up 257 days, 16:49, 2 users, load average: 0.70, 0.73, 0.79
Vic.
Which I guess is why you hear so many stories of companies that fall over and settle just before it gets to court. They'll obstruct, threaten and make you suffer right up to the courtroom door in the hope that you'll give up.
I took Royal Mail to court over some numptiness. It was a tiny claim, but they sent me a full inch of paperwork from their legal department to try to deter me, claiming they'd spent many thousands for which I would be liable when I failed in my suit.
I applied for a court date, and all of a sudden, they sent me a cheque...
VIc.
managers started to measure the Cost of Poor Quality, and wanted to minimise it. That leads to targets
...But it always leads to the *wrong* targets.
Manglement want issues dealt with quickly - but customers don't; they want issues *resolved* quickly. So measuring the average time to close tickets and making a target out of that just motivates call-centre staff to close tickets prematurely. What you really need to measure is the time to get a customer to click the "yes, that's fixed, thanks" button.
But they don't :-(
Vic.
> Does nobody use RT any more?
If you're going to set up RT, you need to be the only developer setting it up.
It's so configurable, it's nigh-on impossible to get a concensus IME.
We had a guy insisting it be set up with more queues than we had employees. As he was a Director (and I wasn't), he got his way...
Bloody good tracker, though.
Vic.
Are you saying the system is "time sharing" the receiver hardware virtually on a frame by frame basis to allow this?
Nope. I'm saying it has multiple tuners and demultiplexers, but probably only one decoder (unless it supports PiP). The decoder genreates the images on your screen; the on-disk storage will still be encoded (for reasons that are obvious, I hope).
Nevertheless, none of that changes what I posted earlier - you still have a time delay between attempting to select a channel and getting that channel's data available on the demux output. You then have a further delay getting that data decoded into images and sound.
Because (apart from incompetent implementation) the only other reason I can think of is that the system powers down the 2nd channel in a rather misguided attempt to save power.
That's because you are thinking of the decoder as a single, monolithic lump. It isn't - you have a tuner, a demultiplexer, and a decoder. Many STBs have multiple tuners and demuxers, but I haven't seen many[1] with multiple decoders
The "common sense" way to implement this function is too effectively switch the outputs of 2 live decoders between a single channel to the monitor, not to have a "primary" and "secondary" decoder and switch the channel inputs between them.
You could build one - but you'd price yourself out of the market. And you still wouldn't get over the inevitable delay in locking the channel - it just does take that time.
Obviously I'd expect switching to a totally new channel to take longer
Exactly.
but the speed of the switching for existing channels is rubbish.
It isn't. Switching to a channel for which you already have demultiplexed data is quicker, but there is still a decoder lock-up time. But that wait time will be less than the time to lock a tuner/demux as well as the decoder.
Vic.
[1] There were some interesting designs to do HD when we were introducing the STi9000 - certain manufacturers were gluing 6 STi3520s to a board and getting them to work together. But that's not something that's likely to make it to market...
My guess is this was programmed by some linear thinking newby and it never occurred to them it's just a case of flipping between existing outputs rather than searching for a "new" channel.
No, it doesn't work like that.
Even if you were using ping-pong tuners for your alternates - and you almost certainly aren't - you still need to lock your decoder clock to the clock reference, find the assorted tables necessary to interpret the ES streams, then wait for a GOP start before you can actually decode anything. And if there is any issue with A/V sync, you might have to delay further.
This, I'm afraid, is the result of both the temporal compression scheme we use for Digital TV and the carousel nature of the tables. A channel *can* improve the rate at which a decoder can lock to it by increasing the rate of PCR and table injection into the stream - but this costs bandwidth (possibly significantly) and offers very little benefit to the channel.
Vic.
can you imagine just how much longer it would take at passport control if you had to enter a PIN ?
Exactly. Passports get used a couple of times a year for most people - most of those PINs will get forgotten, so either they'll be written down on a piece of paper kept with (inside?) the passport - rendering the whole thing useless - or people will cluster around the gate trying desperately to remember a number they last used a year ago.
And then you've got the reliability issue. Given the *huge* number of passports in circulation, there will inevitably be some faulty keyboards. So even if the traveller can remember the PIN, he still can't type it into the passport, so he still misses his flight.
So there you go. Perhaps the article should be re-entitled "Man With Patent Seeks Ways To Make More Money"...
Vic.
Could the first chip perhaps be a TL074 quad op-amp rather than a 74-series logic chip?
I suspect he's mis-remembering a little...
One of the classic guitar distortion designs was to use unbuffered CMOS 4000-series - e.g. the 4009UBE, which gave you 6 stages to play with.
I can't imagine TTL sounding much cop...
Vic.
There are rumors that there were industrial control systems which ran on the PC driven by hardware interrupts, but booted a Windows 3.x as a GUI toolkit.
My reason for knowing this isn't all that dissimilar...
I was building a control/analysis tool with a PC as the user inteface, Due to limitations in the embedded controller hardware, we had to do a data grab in ISR, with a background task to process the raw data and generate trends.
And then they told me to write the UI in LabWindows. It was horrific. I had to re-write most of the DOS scheduler :-(
Vic.
> All system calls were blocking and there was no multitasking
Actually, there *almost* was.
Static data in DOS was supposed to live in the Swappable Data Area, which was referenced by reference to the SDA base pointer. In this way, you could hook a TSR to the timer tick, check the InDOS flag to make sure a context switch was safe, then adjust the SDA pointer to effect a context switch.
It wasn't true multi-tasking, but good enough for rock 'n' roll.
Sadly, as new DOS versions emerged, more and more static data was put somewhere other than the SDA, so new and interesting bugs suddenly popped into existence on version changes, as context migrated between threads :-(
Vic.
The south path -to me- points to an elaborate suicide.
I'm trying to prove you wrong because that would be such an utter waste of time, effort, and humanity. But I keep coming back to agreement with you. Unless there are things going on that we don't know about (and we do know that there is *some* of that).
Whoever did it didn't know about the 'pings' and so had every reason to believe that the plane would never be found
I think that bit shows even more detailed knowledge - the page that someone used to turn off the ACARS VHF transmissions only really has two entries on it - a tick-box for VHF and a tick-box for SATCOM. That someone turned off VHF and not SATCOM implies he thought SATCOM wasn't important - and that implies that he knew Malaysia Airlines wasn't using SATCOM...
Vic.
> Maybe planes should carry some EPIRBs
They carry fuselage-mounted ELTs which can be triggered by the pilot, or trigger themselves automatically in the event of a rapid deceleration.
A detachable unit doesn't serve much purpose - for it to be secure enough to cope with flight, it would need a locking arrangement that will likely be problematical in a crash situation.
Vic.
Autopilot resumes altitude, possibly due to incorrect action on the part of hypoxic flight crew and the rest is history.
No, that's bobbins.
If the automatic systems took over, that would take the aircraft to wherever the flight crew left it flying towards.
That could be :-
- The original destination
- The divert airfield
- A random position because they'd screwed up entering the divert (which is very unlikely)
The aircraft did none of these. Instead, it followed a route by way of three common waypoints that were nothing to do with either the original flight plan or any feasible divert. This means *for sure* that a human changed the planned flight for reasons unknown.
Vic.
> you have separate oxygen supplies for each pilot for at least a while
Do we know that?
The 777 can have either one or two cylinders supplying oxygen for the flight crew. I do not know the configuration of this aircraft (I'm working from the FCOM for some Qatar Airways aircraft).
That bit notwithstanding, the rest of your post is on the money.
Vic.
There was a theory posted on PPRuNe about a week ago by an engineer that quite neatly ticked off many of the elements mentioned above. Well worth a quick read.
...But misses the most important one.
Suppose the O2 bottle were to break free, break all the equipment, and punch a hole in the fuselage in the way suggested. The pilots then have no O2 in a hypoxic environment.
Why did the plane fly to a set of waypoints that were neither in the flight plan nor were a divert? A human had to set those waypoints. This would be impossible if the pilots were not conscious.
Vic.
> Could the reprogramming have been done before takeoff ie on the ground?
Well - yes. But that would mean the pilots were complicit in the disappearance of the aircraft.
> When should it have been done?
It shouldn't. The flight should have been set up when the pilots took command of the aircraft, and their route should match the flightplan they filed,
> Could the pilots not notice?
They would have had to perform the deed, so yes - they would certainly notice...
Vic.
there are computer assists on the 777, but from memory there is a big button on the control column that overrides those computers.
Yes. There's a switch in the overhead panel to disconnect the PFCs.
there is no way to control the plane from the ground like that.
Of course there isn't. But people love to make up "theories"...
Vic.
Saw an item on RT or Al Jazeera about a week or so ago, suggesting that the plane had suffered a decompression for some reason, and that the pilot(s) had been attempting to wind the autopilot around to the reciprocal heading in order to return to KL, but had passed out before completing the task.
That theory is wrong.
777s don't have a "follow this heading" control, they have a database of waypoints and airfields in the Flight Director. The pilot selects where he wants to go, and the plane goes there. They also have neat toys in the FD such as a "divert" mode, where the unit scans its database for the nearest airfield that can handle the aircraft in its current state. So to do the divert, you select the "Alternate" page, hit "Divert", then hit "Accept". The plane takes you to your emergency airfield.
What actually happened is that the aircraft flew through several waypoints, none of which were divert airfields.
Could a pilot regain entry to the anti-hijack cockpit these days if the crew inside were unconscious?
That depends on what state the flight crew had left the door in.
The standard mode has the door locked, but can be opened from the outside by keying in the right code (3 to 8 digits). Each attempt is annunciated inside the cockpit.
The pilot also has a control on the centre console which allows him to open the door, or to reject further attempts to get in for a period of time.
Additionally, the door has deadbolts, which prevent it opening under any circumstances.
Vic.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
