Answer the following questions: a) In which jurisdiction does telephones fall under? b) In which jurisdiction does the internet fall under?
If you don't know, government beauracarcies will fill the gap (several departments will often grab the same space until the courts decide who "owns" the juridiction) rather than let it go unregulated.
StarTrek reflects more of the present world (when an episode was written) than the world of the future. Watching through the original series will tell you more about North American popular culture of the 1960s than what could potentially be around the corner for humanity in several centuries time. Presumably StarTrek TNG is something similar for the 1990s. You call this science fiction? There are other SciFi series who give a better explaination of the future and at least the science they spout is plausible.
No offence to the older generation who reads slashdot but I am getting a little tired of being constantly reminded of the baby boomer generation (those people who could leave high school and almost be guaranteed a job that would put bread on the table, today going through colledge/university can't even do that). To be reminded of the Baby Boomers hedonistic glory days of free love, drugs and peace to all gets a tad revolting.
Wasn't Shatner who told a bunch of Trekie fanatics to "get a life"?
In a lot of countries, being a telecommunications company grants certain rights and privellages (such as access to "right of way" for running cables over government land). In some places these privellages have been abused (such as installing cellular telephone towers).
My question is these local government taxes (state and/or municipal) a form of check and balances for granting phone companies certain rights and privs?
ZombieEngineer
PS: I live south of the equator so please forgive me if the actions of your government appear to be spinning in the opposite direction to what I am used to.
A bit of background history for the parport driver. This original started by two guys (Philip Blundell and Tim Waugh) blabbering about treating the parallel port as bus. There was something like ten e-mails for a couple of days while most of the regulars were scratching their heads.
The parallel port ZIP drive maintainer asked them to provide a function prototype of this thing that they were talking about, of them (Phil/Tim) quickly whipped up a rough 50 line C header file which was turned into a working parport driver + parport enabled ZIP and printer driver (removing the infamous "printer-on-fire" message in the process). There were bugs in the parport driver (it was the first pass but you could print and use the ZIP drive together which was something that previously could not be done) but Phil/Tim/Andrea quickly pounced on the driver and straighten it out. Some of the routines for supporting NatSemi and SMC chipsets are there due to the ZIP drive maintainer not being able to use EPP mode on his Dell desktop.
When Andrea first appeared on the parallel port scene he was lacking a little confidence (appologising for his poor english which was far better than my italian:-) but once he got his feet wet with kernel hacking there was nothing stopping him.
Unfortunately I dropped out of the parallel port group around 2000 due to work commitments (linux hacking was one of those phases that I went through).
I congratulate Andrea on where his life has taken him.
Your typical 747 cruises between 36,000 ft and 44,000 ft. Air density starts thinning out dramatically at these altitudes hence the maximum possible altitude for a civilian aircraft would be say 50,000 ft (15.3 km straight up).
The only possible exception would a supersonic aircraft but there isn't too many of those in civilian hands.
There is a large number of cases in the engineering world where running something continously flat out is far better than starting and stopping. Cases that come to mind are gas turbines (gas turbines for power generation have a lifetime measured in 100s of starts, the number 500 springs to mind). There is also a class of heat exchangers (printed circuit heat exchangers, transfers approx 5 to 15 MW of heat in a block of aluminium the size of a typical car engine) which are also very sensitive to thermal cycling.
I am probably going to be branded a troll for this but...
A lot of TV programs are supported by advertisments (no brainer), the other option is a hideously high (relatively) subscription cost for an advert free video stream. With the latest developments with video recording it forces a change in the business model for the media industry.
If we assume that adverts are required to support our favourite programs (a necessary evil), is there a way to have our recording devices to select our prefered category of advertising?, eg: we prefer to see adds for tech gadgets over medical products over personal injury lawyers.
The selection of the order for the adverts could be done using a statistical method (show four random categories, ask the user to chose the most prefered and least prefered advert categories, repeat 20 times).
This will result in better product placement to people who are willing to consider your product. Hence a 25 year old will never see a Fixodent (denture glue) advert because his recorder will steer away from those adverts, the current alternative is the advert is simply totally ignored by the viewer and does nothing but increase the resentment of adverts.
The comments on Wait(0) are interesting and valid (I have made the same observations).
The main calculation thread is a monolithic chunk of FORTRAN code (the code base harks back to the days of VAX machines with limited CPU and memory). Mixing FORTRAN and Win32 API calls is not a job for the faint hearted.
It is not the GUI that starts to "flake out" rather the response on the communications thread which responds to a packet comming in on a TCP/IP port. The packet processing for the DCS interface is typically arround 20 to 100 packets/second.
What actually happens is that the interface will run for a fraction of a timeslice then the scheduler runs the main calc thread for the remainder of the timeslice plus the next timeslice. Therefore the maximum requests per second is approximately 50 packets/second, if the load from the DCS is higher that this, a backlog builds up to the point where a three second timeout period has been exceeded. I guess the issue here is the granularity of the timeslice size when working with real-time or near real-time systems.
I have found HyperThreading a real boost for developing operator training simulators (think giant custom computer game for process plant operators [eg: Oil refineries, gas plants, chemicals, etc...]) where the a single thread will totally consume the resources of a single CPU (we call it "no-wait" where the simulation calculates what happens in the next 2 seconds and then immediately jumps to the next timestep, thus fast forwarding through slow parts of a process start-up such as warming a reactor).
An issue we encounter is the DCS (Distributed Control System) interface (the bit that links the PC to the fancy membrane keyboards, touch screens, alarm annunciators that the operator uses on the real plant [to maximise training benefit]). Although the interface typically only uses 0.5 to 2% of the CPU, when the simulation goes flat out, there is a noticable impact on other threads to the point where there is timeouts on data requests from the operator console.
In summary, if you have a system where some threads are IO bound (in our case, processing requests coming across via ethernet) and other threads are CPU intensive (high end numerical calculations) you will see a definite benifit. It allows us to give every team member a machine fit for the job at approximately 1/3 the cost (those of you who wish to argue that SMP machines are cheaper, we are bound by corporate purchasing agreements where SMP falls into the "Workstation" catagory while a uni-processor HT machine falls into the far cheaper "Desktop" catagory).
If you are performing just purely calculations and need to run two parallel threads, I would recommend a SMP or similar machine.
Slashdot Mirror
SoundForge is not SourceForge.
Please read the Google translated article for clarification.
da ZombieEngineer
I vaugely recall that Centrelink's network was the largest in the southern hemisphere (by user/node count).
Could anyone please confirm/refute this?
ZombieEngineer
Answer the following questions:
a) In which jurisdiction does telephones fall under?
b) In which jurisdiction does the internet fall under?
If you don't know, government beauracarcies will fill the gap (several departments will often grab the same space until the courts decide who "owns" the juridiction) rather than let it go unregulated.
ZombieEngineer
ZombieEngineer
No offence to the older generation who reads slashdot but I am getting a little tired of being constantly reminded of the baby boomer generation (those people who could leave high school and almost be guaranteed a job that would put bread on the table, today going through colledge/university can't even do that). To be reminded of the Baby Boomers hedonistic glory days of free love, drugs and peace to all gets a tad revolting.
Wasn't Shatner who told a bunch of Trekie fanatics to "get a life"?
ZombieEngineer
I thought today after Y2K, why do we need to be reminded of the 1960's?
ZombieEngineer
CaC03 + Heat => CaO + CO2
Happens around 200'C from memory.
ZombieEngineer
My question is these local government taxes (state and/or municipal) a form of check and balances for granting phone companies certain rights and privs?
ZombieEngineer
PS: I live south of the equator so please forgive me if the actions of your government appear to be spinning in the opposite direction to what I am used to.
The parallel port ZIP drive maintainer asked them to provide a function prototype of this thing that they were talking about, of them (Phil/Tim) quickly whipped up a rough 50 line C header file which was turned into a working parport driver + parport enabled ZIP and printer driver (removing the infamous "printer-on-fire" message in the process). There were bugs in the parport driver (it was the first pass but you could print and use the ZIP drive together which was something that previously could not be done) but Phil/Tim/Andrea quickly pounced on the driver and straighten it out. Some of the routines for supporting NatSemi and SMC chipsets are there due to the ZIP drive maintainer not being able to use EPP mode on his Dell desktop.
When Andrea first appeared on the parallel port scene he was lacking a little confidence (appologising for his poor english which was far better than my italian :-) but once he got his feet wet with kernel hacking there was nothing stopping him.
Unfortunately I dropped out of the parallel port group around 2000 due to work commitments (linux hacking was one of those phases that I went through).
I congratulate Andrea on where his life has taken him.
ZombieEngineer
Formerly-the-hacker-who-maintained-linux-zip-drive rs.
Your typical 747 cruises between 36,000 ft and 44,000 ft. Air density starts thinning out dramatically at these altitudes hence the maximum possible altitude for a civilian aircraft would be say 50,000 ft (15.3 km straight up).
The only possible exception would a supersonic aircraft but there isn't too many of those in civilian hands.
Da ZombieEngineer
There is a large number of cases in the engineering world where running something continously flat out is far better than starting and stopping. Cases that come to mind are gas turbines (gas turbines for power generation have a lifetime measured in 100s of starts, the number 500 springs to mind). There is also a class of heat exchangers (printed circuit heat exchangers, transfers approx 5 to 15 MW of heat in a block of aluminium the size of a typical car engine) which are also very sensitive to thermal cycling.
ZombieEngineer
I am probably going to be branded a troll for this but...
A lot of TV programs are supported by advertisments (no brainer), the other option is a hideously high (relatively) subscription cost for an advert free video stream. With the latest developments with video recording it forces a change in the business model for the media industry.
If we assume that adverts are required to support our favourite programs (a necessary evil), is there a way to have our recording devices to select our prefered category of advertising?, eg: we prefer to see adds for tech gadgets over medical products over personal injury lawyers.
The selection of the order for the adverts could be done using a statistical method (show four random categories, ask the user to chose the most prefered and least prefered advert categories, repeat 20 times).
This will result in better product placement to people who are willing to consider your product. Hence a 25 year old will never see a Fixodent (denture glue) advert because his recorder will steer away from those adverts, the current alternative is the advert is simply totally ignored by the viewer and does nothing but increase the resentment of adverts.
ZombieEngineer
The comments on Wait(0) are interesting and valid (I have made the same observations).
The main calculation thread is a monolithic chunk of FORTRAN code (the code base harks back to the days of VAX machines with limited CPU and memory). Mixing FORTRAN and Win32 API calls is not a job for the faint hearted.
It is not the GUI that starts to "flake out" rather the response on the communications thread which responds to a packet comming in on a TCP/IP port. The packet processing for the DCS interface is typically arround 20 to 100 packets/second.
What actually happens is that the interface will run for a fraction of a timeslice then the scheduler runs the main calc thread for the remainder of the timeslice plus the next timeslice. Therefore the maximum requests per second is approximately 50 packets/second, if the load from the DCS is higher that this, a backlog builds up to the point where a three second timeout period has been exceeded. I guess the issue here is the granularity of the timeslice size when working with real-time or near real-time systems.
ZombieEngineer
I have found HyperThreading a real boost for developing operator training simulators (think giant custom computer game for process plant operators [eg: Oil refineries, gas plants, chemicals, etc...]) where the a single thread will totally consume the resources of a single CPU (we call it "no-wait" where the simulation calculates what happens in the next 2 seconds and then immediately jumps to the next timestep, thus fast forwarding through slow parts of a process start-up such as warming a reactor).
An issue we encounter is the DCS (Distributed Control System) interface (the bit that links the PC to the fancy membrane keyboards, touch screens, alarm annunciators that the operator uses on the real plant [to maximise training benefit]). Although the interface typically only uses 0.5 to 2% of the CPU, when the simulation goes flat out, there is a noticable impact on other threads to the point where there is timeouts on data requests from the operator console.
In summary, if you have a system where some threads are IO bound (in our case, processing requests coming across via ethernet) and other threads are CPU intensive (high end numerical calculations) you will see a definite benifit. It allows us to give every team member a machine fit for the job at approximately 1/3 the cost (those of you who wish to argue that SMP machines are cheaper, we are bound by corporate purchasing agreements where SMP falls into the "Workstation" catagory while a uni-processor HT machine falls into the far cheaper "Desktop" catagory).
If you are performing just purely calculations and need to run two parallel threads, I would recommend a SMP or similar machine.
As always your milage may vary.
ZombieEngineer