Having gone from a Perforce to SVN shop, I can definitely say that I prefer the SVN way of working.
Under Perforce all files in your workspace are marked read only, and you have to use a Perforce client to change them to read-write, which is then tracked by the server (kinda like ci/co). This can be a pain when working away from the server as you have to manually edit permissions and then run a lengthy command when back in office to make a changelist from the files you've edited, otherwise you may miss changed files on your next submission. Similarly under Perforce it is all to easy to add a file and forget to tell the Perforce client and then fail to submit it.
SVN just lets you edit everything and add files then svn status shows you what's changed. TortoiseSVN overlays icons to show what you've changed in explorer, which is just excellent and makes it soo easy to see what you've worked on.
Another great thing with SVN is that you can still revert and diff files without contacting the server. With Perforce, if you are working remote, you are on your own and need to keep a backup of changes yourself if you wish to revert them without accessing the server.
Both have good features, but I definitely prefer sub-version, mainly due to it's simplicity and good support for remote working (I'm hoping the log caches in 1.5 will allow some access to file history without the server too).
Me too. I'm stuck at Fedora 5 since that seems to be the only release for which the graphics drivers for a Via EPIA EX1500 actually allow the Tv output to work. Unfortunately I had to spend ages patching PCI tables and similar in the Kernel to get other bits of the board working, and I've still not got the audio drivers going:(
To date, VIAs Linux support is really poor. I see a lot of noise coming from VIA about Open Source, but I'm yet to see any fruits.
Also, had the Via Arena forums not been erased when being replaced by the new TK Arena forums, you'd have been able to see many many posts complaining about driver support and frustrated users trying to work out how to get their boards working. Still, the TK Arena hasn't been up that long, but some of the posts are already starting to look familiar:
I'm not sure whether the comment was intended to be funny or not.
But I think you are correct. Java has synchronisation primitives built into the language and the standard libraries have lots of concurrent save types (e.g. a Vector can be used like a thread safe ArrayList). Compared to other languages where the concurrency is a bolt on (sorry pthreads), this really does make it easy to thread an app and get the synchronisation correct. Sun's tutorial goes into more depth:
Via have had a long time to make good drivers, and there are already OSS projects to which they could have contributed i.e. the OpenChrome or Unichrome drivers. However, they chose to release their own binaries for limited and very old distros, and provided source with a nightmare compile process (see my experiences here: http://slashdot.org/comments.pl?sid=430420&cid=22186390). If they really wanted to help they could have given the data sheets to these projects and maybe send them some development platforms for free.
It really does seem that this move comes after a long period of letting their Linux support stagnate. If anything, I'm sceptical and wouldn't be surprised if this is Via solution to their Linux problem, and are now hoping the community will fix them up with little investment from themselves.
I hope I am wrong, and Via will really be actively involved in supporting driver development at every opportunity.
I'd argue for weighted fair queuing and QOS in the cable box.
Seem to me that for ADSL it would be ideally placed in the DSLAM, where there is already a per-subscriber connection (in any case, most home users will only get 1 IP address, hence making a 1:1 mapping for subscriber to IP -nothing need be per IP connection as the original article assumes). In fact, the wikipedia page on DSLAMs says QoS is already an additional feature, mentioning priority queues.
So I'm left wondering why bandwidth hogs are still a problem for ADSL. You say that this is a "huge collection of tuning parameters", and I accept that correctly configuring this stuff maybe complex, but this is surely the job of the ISPs. Maybe I'm overestimating the capabilities of the installed DSLAMs, in which case I wonder if BTs 21CN will help.
Certainly though, none of the ISPs seem to be talking about QoS per subscriber. Instead they prefer to differentiate services, ranking P2P and streaming lower than uses on the subscribers behalf. PlusNet (a prominent UK ISP) have a pizza analogy to illustrate how sharing works - using their analogy, PlusNet would give you lots of Margarita slices, but make you wait for a Hawaiian even if you aren't eating anything else. Quite why they think this is acceptable is unknown to me; they should be able to enforce how many slices I get at the DSLAM, but still allow me to select the flavours at my house (maybe I get my local router to apply QoS policies when it takes packets from the LAN to the slower ADSL, or mark streams using TOS bits in IPv4 or the much better IPv6 QoS features to assist the shaping deeper into the network).
Right. The article seems to be written on the assumption that the bandwidth bottleneck is always in the first few hops, within the ISP. And in many cases for home users this is probably reasonably true; ISPs have been selling cheap packages with 'unlimited' and fast connections on the assumption that people would use a fraction of the possible bandwidth. More fool the ISPs that people found a use for all that bandwidth they were promised.
Obviously AIMD isn't going to fix this situation - it's not designed to. Similarly, expecting all computers to be updated in any reasonable timeframe won't happen (especially as a P2P user may have less little motivation to 'upgrade' to receive slower downloads). Still, since we're assuming the bottleneck is in the first hops, it follows that the congestion is in the ISPs managed network. I don't see why the ISP can't therefore tag and shape traffic so that their routers equally divide available bandwidth between each user, not TCP stream. Infact, most ISPs will give each home subscriber only 1 IP address at any point in time, so it should be easy to relate a TCP stream (or and IP packet type) to a subscriber. While elements of the physical network are always shared, each user can still be given logical connection with guaranteed bandwidth dimensions. This isn't a new concept either, it's just multiplexing using a suitable scheduler, such as rate-monotonic (you get some predefined amount) or round-robin (you get some fraction of the available amount).
Such 'technology' could be rolled by ISPs according their roadmaps (although here in the UK it may require convincing BT Wholesale to update some of their infrastructure) and without requiring all users to upgrade their software or make any changes. However, I suspect here the "The politicization of an engineering problem" occurs because ISPs would rather do anything but admit they made a mistake in previous marketing of their services, raise subscriber prices, or make the investment to correctly prioritise traffic on a per user basis, basically knocking contention rates right down to 1:1. It's much easier to simply ban or throttle P2P applications wholesale and blame high bandwidth applications.
I have little sympathy for ISPs right now; the solution should be within their grasp.
wireframe vector graphics in Spectrum BASIC anyone? Anyone? No, didn't think so...
Uh? Don't you remember the CIRCLE, PLOT and DRAW commands? Sure they were slow (I can remember watching as large circles were drawn clockwise to the screen), but they were there.
These devices are only used to disperse gangs which have already accumulated and who are causing trouble.
They are not emitting this sound on a constant basis, and are just fired for very short periods of time as required.
Not true. Meldreth railway station in Cambridgeshire, UK has one of these devices mounted on a post such that it is audible from the only covered waiting areas on both platforms. It appears to be activated by a combination of timer and passive infra-red sensor, and unfortunately I've witnessed it being triggered by high speed trains passing through the station. The station itself carries warning signs saying that a mosquito device is in use on the station.
I have an issue with this usage. It is completely legitimate and very likely that children, families and babies can be waiting on the train platform, yet are subject to this device. Additionally I can hear the bloody thing (I'm 29 and not misbehaving), and while there are signs indicating the device is in use at the location, none give contact details for information or complaints.
While I appreciate the station has suffered problems with yobs, this device only adds to the unpleasantness of waiting for the train. The device should be removed from this location and such indiscriminate usage should be regulated, maybe through planning permission requirements.
You're right. But the poster has as point. The Unichrome support is really bad on Linux. There are about 3 different drivers to try, all with differing results:
- The OpenChrome drivers, open source, some hw-accel support - Unichrome drivers, open source but taking a purist approach that lacks features - Via's own drivers, limited binaries for only certain distros, nightmare compile process, but most features supported
Unfortunately for me, I bought a VIA-epia ex1000 mini-ITX. It has some nice TV out connectors (component out!), so needs a driver that knows how to get this going. Having wasted a lot of time trying to build the drivers for FC7, I gave up and ended up using the Via binaries with FC5. The problem then is that other bits of hardware aren't detected under FC5, leaving me to patch PCI tables and rebuild the kernel to get the right southbridge driver (made a big difference to system performance - much smoother) and the SMBUS working.
Personally I think the problem is with Via. They claim to support open source, but throwing out the odd binary driver and giving mangled sources with not too easy to follow build instructions isn't much more than lip service. If they were serious, they could setup a yum repository for Fedora and make rpm's and debs for each major release of the distros they choose to support. Putting all the download packages on one page of their site would also help, as would openly releasing all their datasheets.
I hope they learn to do better, because I feel their products are held back by the poor Linux support:(
Thats right, P2P content distributors are nothing more than freeloaders.
I've tried both 4od and the BBC iPlayer, to find that these apps silently start a P2P service (Kontiki) on my computer and will use that to distribute their content, eating as much bandwidth as it can take. Notably this service has no dialog, task tray icon or any other obvious control mechanisms, and always auto starts at boot, re-enabling itself when 4od is launched if it is disabled..
So, if this is what Cuban means by P2P content distributors, I think he's right. Channel 4 is funded through advertising, and forces me to watch ads before any programs I download, while I pay a license fee for the BBC. And I pay for my bandwidth, which is also capped at 20GB/month, so neither unlimited nor free.
Personally I think these video player apps are nothing more than Trojan horses, which undoubtedly are going to cause both consumers and ISPs problems as they wonder where all their bandwidth has gone, or how they managed to exceed their bandwidth cap.
Updating firmware?
Questions as to whether why the AAK-firmware exists are still not answered. A sad detail is that updating an AAK disk to other firmware is impossible, due to physical differences of the two disks.
I'm not sure where the article got this from, but it implies that it could still be a hardware difference (e.g. slightly lower spec'd DSP in the controller?)
I looked through the paper, and it is cool stuff. But I couldn't see where it supposed the system would work well for other languages, and I wonder if it really would be so good.
Java has a very large standard library that is always dynamically linked, and hence can easily be instrumented as the technique requires. C allows static linking which would make such hooking much more difficult. Additionally Java executes in a very standard environment due to the Virtual Machine, where as other languages may have varying ABIs type sizes and other properties that could add significant noise to the birthmark.
That said, system calls are always hookable and reasonably standard, so maybe this technique could be applied successfully there for malware detection or similar?
They submitted a unit, that when tested failed. Why would you waste time trying a second device? If the second passed the tests, the overall result must still be inconclusive since the first unit failed.
The only case I can think of in which the backup could sensibly be used, would be if some other defect prevented the testing of the first unit e.g. it was physically damaged, had a flat battery or couldn't start testing for some other non-performance related reason.
Sounds like a schoolboy error on Microsoft's part. No big deal though, I'm sure they will be back to retest when the unit is fixed - these things happen.
Could you not eliminate arm motion with a very fast rotating mirror, constantly passing the laser across the rotating disk? Then you just have the problem of rapidly switching the laser on and off to target the specific track.
and have access to all iPhone internal services, such as phone dialing, access to maps functionality, and any other iPhone services
Am I the only person that's terrified by the idea of allowing web browser apps to start dialling people? I really hope they get the security model correct.
Slashdot Mirror
So a new f00f bug then?
http://en.wikipedia.org/wiki/F00f
Having gone from a Perforce to SVN shop, I can definitely say that I prefer the SVN way of working.
Under Perforce all files in your workspace are marked read only, and you have to use a Perforce client to change them to read-write, which is then tracked by the server (kinda like ci/co). This can be a pain when working away from the server as you have to manually edit permissions and then run a lengthy command when back in office to make a changelist from the files you've edited, otherwise you may miss changed files on your next submission. Similarly under Perforce it is all to easy to add a file and forget to tell the Perforce client and then fail to submit it.
SVN just lets you edit everything and add files then svn status shows you what's changed. TortoiseSVN overlays icons to show what you've changed in explorer, which is just excellent and makes it soo easy to see what you've worked on.
Another great thing with SVN is that you can still revert and diff files without contacting the server. With Perforce, if you are working remote, you are on your own and need to keep a backup of changes yourself if you wish to revert them without accessing the server.
Both have good features, but I definitely prefer sub-version, mainly due to it's simplicity and good support for remote working (I'm hoping the log caches in 1.5 will allow some access to file history without the server too).
Yeah, that's the +l option (set per file), usually used for binary files that can't easily be diffed, hence have to be edited exclusively:
http://www.perforce.com/perforce/doc.042/manuals/p4guide/04_details.html#1047746
> SVN free clients are 'not good' on windows
TortoiseSVN is very good and integrates with Windows explorer really really well (if you like that sort of thing).
Anytime I've travelled through an airport in the last couple of years....
Me too. I'm stuck at Fedora 5 since that seems to be the only release for which the graphics drivers for a Via EPIA EX1500 actually allow the Tv output to work. Unfortunately I had to spend ages patching PCI tables and similar in the Kernel to get other bits of the board working, and I've still not got the audio drivers going :(
To date, VIAs Linux support is really poor. I see a lot of noise coming from VIA about Open Source, but I'm yet to see any fruits.
Hi,
:(
I've had first hand experience of trying to get a Via EPIA EX1000 working nicely, and it was a bitter experience, see my previous posting here:
http://slashdot.org/comments.pl?sid=430420&cid=22186390
Also, had the Via Arena forums not been erased when being replaced by the new TK Arena forums, you'd have been able to see many many posts complaining about driver support and frustrated users trying to work out how to get their boards working. Still, the TK Arena hasn't been up that long, but some of the posts are already starting to look familiar:
http://www.tkarena.com/forums/video-graphics-arena/34947-tv-out-problems-cn700-chipset.html
I do hope things improve, but somehow I think I'm stuck on Fedora 5 for my Via EPIA board
Or even sound through Mercury Delay lines...
I'm not sure whether the comment was intended to be funny or not.
But I think you are correct. Java has synchronisation primitives built into the language and the standard libraries have lots of concurrent save types (e.g. a Vector can be used like a thread safe ArrayList). Compared to other languages where the concurrency is a bolt on (sorry pthreads), this really does make it easy to thread an app and get the synchronisation correct. Sun's tutorial goes into more depth:
http://java.sun.com/docs/books/tutorial/essential/concurrency/locksync.html
Via have had a long time to make good drivers, and there are already OSS projects to which they could have contributed i.e. the OpenChrome or Unichrome drivers. However, they chose to release their own binaries for limited and very old distros, and provided source with a nightmare compile process (see my experiences here: http://slashdot.org/comments.pl?sid=430420&cid=22186390). If they really wanted to help they could have given the data sheets to these projects and maybe send them some development platforms for free.
It really does seem that this move comes after a long period of letting their Linux support stagnate. If anything, I'm sceptical and wouldn't be surprised if this is Via solution to their Linux problem, and are now hoping the community will fix them up with little investment from themselves.
I hope I am wrong, and Via will really be actively involved in supporting driver development at every opportunity.
The answer to these questions is of course 'yes', but 'shouldn't' is the operative word here.
And now you come to realise why so much software sucks.
Seem to me that for ADSL it would be ideally placed in the DSLAM, where there is already a per-subscriber connection (in any case, most home users will only get 1 IP address, hence making a 1:1 mapping for subscriber to IP -nothing need be per IP connection as the original article assumes). In fact, the wikipedia page on DSLAMs says QoS is already an additional feature, mentioning priority queues.
So I'm left wondering why bandwidth hogs are still a problem for ADSL. You say that this is a "huge collection of tuning parameters", and I accept that correctly configuring this stuff maybe complex, but this is surely the job of the ISPs. Maybe I'm overestimating the capabilities of the installed DSLAMs, in which case I wonder if BTs 21CN will help.
Certainly though, none of the ISPs seem to be talking about QoS per subscriber. Instead they prefer to differentiate services, ranking P2P and streaming lower than uses on the subscribers behalf. PlusNet (a prominent UK ISP) have a pizza analogy to illustrate how sharing works - using their analogy, PlusNet would give you lots of Margarita slices, but make you wait for a Hawaiian even if you aren't eating anything else. Quite why they think this is acceptable is unknown to me; they should be able to enforce how many slices I get at the DSLAM, but still allow me to select the flavours at my house (maybe I get my local router to apply QoS policies when it takes packets from the LAN to the slower ADSL, or mark streams using TOS bits in IPv4 or the much better IPv6 QoS features to assist the shaping deeper into the network).
Right. The article seems to be written on the assumption that the bandwidth bottleneck is always in the first few hops, within the ISP. And in many cases for home users this is probably reasonably true; ISPs have been selling cheap packages with 'unlimited' and fast connections on the assumption that people would use a fraction of the possible bandwidth. More fool the ISPs that people found a use for all that bandwidth they were promised.
Obviously AIMD isn't going to fix this situation - it's not designed to. Similarly, expecting all computers to be updated in any reasonable timeframe won't happen (especially as a P2P user may have less little motivation to 'upgrade' to receive slower downloads). Still, since we're assuming the bottleneck is in the first hops, it follows that the congestion is in the ISPs managed network. I don't see why the ISP can't therefore tag and shape traffic so that their routers equally divide available bandwidth between each user, not TCP stream. Infact, most ISPs will give each home subscriber only 1 IP address at any point in time, so it should be easy to relate a TCP stream (or and IP packet type) to a subscriber. While elements of the physical network are always shared, each user can still be given logical connection with guaranteed bandwidth dimensions. This isn't a new concept either, it's just multiplexing using a suitable scheduler, such as rate-monotonic (you get some predefined amount) or round-robin (you get some fraction of the available amount).
Such 'technology' could be rolled by ISPs according their roadmaps (although here in the UK it may require convincing BT Wholesale to update some of their infrastructure) and without requiring all users to upgrade their software or make any changes. However, I suspect here the "The politicization of an engineering problem" occurs because ISPs would rather do anything but admit they made a mistake in previous marketing of their services, raise subscriber prices, or make the investment to correctly prioritise traffic on a per user basis, basically knocking contention rates right down to 1:1. It's much easier to simply ban or throttle P2P applications wholesale and blame high bandwidth applications.
I have little sympathy for ISPs right now; the solution should be within their grasp.
Uh? Don't you remember the CIRCLE, PLOT and DRAW commands? Sure they were slow (I can remember watching as large circles were drawn clockwise to the screen), but they were there.
Examples are here: http://www.1000bit.net/support/manuali/zxspectrum/chapter_17.htm
That's really cool, and similar to something I was thinking of doing. However, I'd probably just use this nifty little board as it has the AVR and Ethernet already on it: http://shop.tuxgraphics.org/electronic/eth.html?id=24ad20#article06061smd
Not true. Meldreth railway station in Cambridgeshire, UK has one of these devices mounted on a post such that it is audible from the only covered waiting areas on both platforms. It appears to be activated by a combination of timer and passive infra-red sensor, and unfortunately I've witnessed it being triggered by high speed trains passing through the station. The station itself carries warning signs saying that a mosquito device is in use on the station.
I have an issue with this usage. It is completely legitimate and very likely that children, families and babies can be waiting on the train platform, yet are subject to this device. Additionally I can hear the bloody thing (I'm 29 and not misbehaving), and while there are signs indicating the device is in use at the location, none give contact details for information or complaints.
While I appreciate the station has suffered problems with yobs, this device only adds to the unpleasantness of waiting for the train. The device should be removed from this location and such indiscriminate usage should be regulated, maybe through planning permission requirements.
You're right. But the poster has as point. The Unichrome support is really bad on Linux. There are about 3 different drivers to try, all with differing results:
:(
- The OpenChrome drivers, open source, some hw-accel support
- Unichrome drivers, open source but taking a purist approach that lacks features
- Via's own drivers, limited binaries for only certain distros, nightmare compile process, but most features supported
Unfortunately for me, I bought a VIA-epia ex1000 mini-ITX. It has some nice TV out connectors (component out!), so needs a driver that knows how to get this going. Having wasted a lot of time trying to build the drivers for FC7, I gave up and ended up using the Via binaries with FC5. The problem then is that other bits of hardware aren't detected under FC5, leaving me to patch PCI tables and rebuild the kernel to get the right southbridge driver (made a big difference to system performance - much smoother) and the SMBUS working.
Looking at forums I'm definitely not alone. This guy ended up with XP: http://cg-note.blogspot.com/2007/09/via-epia-ex1000-installation-adventure.html
Personally I think the problem is with Via. They claim to support open source, but throwing out the odd binary driver and giving mangled sources with not too easy to follow build instructions isn't much more than lip service. If they were serious, they could setup a yum repository for Fedora and make rpm's and debs for each major release of the distros they choose to support. Putting all the download packages on one page of their site would also help, as would openly releasing all their datasheets.
I hope they learn to do better, because I feel their products are held back by the poor Linux support
Mike
I've tried both 4od and the BBC iPlayer, to find that these apps silently start a P2P service (Kontiki) on my computer and will use that to distribute their content, eating as much bandwidth as it can take. Notably this service has no dialog, task tray icon or any other obvious control mechanisms, and always auto starts at boot, re-enabling itself when 4od is launched if it is disabled..
So, if this is what Cuban means by P2P content distributors, I think he's right. Channel 4 is funded through advertising, and forces me to watch ads before any programs I download, while I pay a license fee for the BBC. And I pay for my bandwidth, which is also capped at 20GB/month, so neither unlimited nor free.
Personally I think these video player apps are nothing more than Trojan horses, which undoubtedly are going to cause both consumers and ISPs problems as they wonder where all their bandwidth has gone, or how they managed to exceed their bandwidth cap.
From the article:
I'm not sure where the article got this from, but it implies that it could still be a hardware difference (e.g. slightly lower spec'd DSP in the controller?)
I looked through the paper, and it is cool stuff. But I couldn't see where it supposed the system would work well for other languages, and I wonder if it really would be so good.
Java has a very large standard library that is always dynamically linked, and hence can easily be instrumented as the technique requires. C allows static linking which would make such hooking much more difficult. Additionally Java executes in a very standard environment due to the Virtual Machine, where as other languages may have varying ABIs type sizes and other properties that could add significant noise to the birthmark.
That said, system calls are always hookable and reasonably standard, so maybe this technique could be applied successfully there for malware detection or similar?
They submitted a unit, that when tested failed. Why would you waste time trying a second device? If the second passed the tests, the overall result must still be inconclusive since the first unit failed.
The only case I can think of in which the backup could sensibly be used, would be if some other defect prevented the testing of the first unit e.g. it was physically damaged, had a flat battery or couldn't start testing for some other non-performance related reason.
Sounds like a schoolboy error on Microsoft's part. No big deal though, I'm sure they will be back to retest when the unit is fixed - these things happen.
I consider most of the code I write to be pretty.
t ar.gz
Here's a link to some source: http://www.mcternan.co.uk/ArmStackUnwinding/wind.
Or you could just use two mirrors, one spinning near the laser source, and a second to deflect the beam down onto the surface.
Could you not eliminate arm motion with a very fast rotating mirror, constantly passing the laser across the rotating disk? Then you just have the problem of rapidly switching the laser on and off to target the specific track.
Am I the only person that's terrified by the idea of allowing web browser apps to start dialling people? I really hope they get the security model correct.