Messages

1

General Software Discussion / Re: SyncBackSE vs. SuperFlexible

« on: November 25, 2007, 05:12 AM »

Tobias, will SFFS put anything in the log for inaccessible folders/files? I guess that would be a good way for people to make sure that it's doing what they need with the service settings they are using.

- Neil.

2

General Software Discussion / Re: SyncBackSE vs. SuperFlexible

« on: November 25, 2007, 04:13 AM »

Just to clarify, when I say "pretty sure it's supposed to" work with the user/pass filled in, what I mean is: that's how I've got it set up, and it seems to be working.

- Neil.

3

General Software Discussion / Re: SyncBackSE vs. SuperFlexible

« on: November 25, 2007, 04:09 AM »

Glad you got it working, J-Mac. It sounded like you were having a bit of a nightmare there.

I think the only thing that you'll be missing with the blank username/password is the ability for SFFS to access your user files when you are logged out (at least, I think that's the case). Not sure if this is an issue for you or not?

As to why it wasn't working with the user/pass filled in, that's a strange one - I'm pretty sure it's supposed to. In fact, I was under the impression that the user/pass aspect of services was a standardised thing, i.e. the user/pass is stored by Windows and you can access it via the Services tool. If you open up Services and get the properties on the ExtremeSync service, you can set the user/pass via its "Log On" tab. Maybe setting it here will work better for you? Apologies if you've already tried this.

- Neil.

4

General Software Discussion / Re: SyncBackSE vs. SuperFlexible

« on: November 24, 2007, 07:05 PM »

J-Mac, which version of SFFS are you using (standard or pro)?

5

General Software Discussion / Re: SyncBackSE vs. SuperFlexible

« on: November 17, 2007, 08:08 AM »

I just got "bit" by the scheduling feature in SFFS. I thought it was scheduled for earlier this afternoon but a reboot of my PC naturally had shut down SFFS and it is not set to auto-start, so - nothing happened.

-J-Mac (November 16, 2007, 03:58 PM)

Do you have the Pro version, or just Standard? I was also a bit perturbed by the way the scheduling worked until I decided to try it with the ExtremeSync service installed (only available with Pro). With this, it behaves much more like you'd expect a backup program to work, i.e. you can fiddle with profiles and pretty much anything else without having to disable scheduling, not to mention allowing scheduling even if you are logged off.

It's a bit of a pity you have to buy Pro to get scheduling working this way though.

This is one of the poorest UI's I have seen in a while. It does sync fast and true, but I now know that I have to be exceedingly careful about every setting and test them all in every conceivable situation, as the developers have not put the customers' ease of use anywhere near the top of the feature list!

-J-Mac (November 16, 2007, 03:58 PM)

Before trying SFFS, I'd seen quite a few comments and reviews saying that the interface was great, so I was a bit confused when I found it to be messy and inconsistent - I began to wonder if I was missing "the point" somehow, but I'm now pretty convinced that the interface is a bit of a mess.

To be fair, it's probably hard to provide as many options as SFFS does without things getting a tad messy, but I do think it could be massively improved. For a start, since there's so many options, I'd like much more control over unifying options across multiple profiles, or some form of option inheritance (e.g. I've got 8 backup jobs, all using the same core settings, but scheduled at different frequencies).

That said, it's not like I'm changing options on a daily basis, and the speed and reliability of SFFS is as good as anything I've seen, so the dodgy interface isn't enough to make me want to change to anything else any time soon.

- Neil

6

General Software Discussion / Re: Interface Design Desperation.. Help needed!

« on: November 02, 2006, 01:34 PM »

How about EasyPrototype?

It's not free, but there's a 30 day eval which is apparently fully functional, although sometimes people say "fully functional" when they mean "doesn't allow saves", so might be worth checking that before you do too much with it.

7

Living Room / Re: Mobo dying .... suggestions please on upgrading my system ...

« on: November 02, 2006, 06:57 AM »

Unfortunately, you can't be sure that it's the IDE controller chip that's dying. It's probably more likely to be one of the big capacitors you see dotted around the board affecting the IDE chip (or its interface to the system) in some way. The lifespan of these capacitors is pretty poor, which is why some of the latest boards have a new type of capacitor that apparently lives a lot longer.

Mind you, although I say "can't be sure", there is one way to find out...

8

Living Room / Re: Best way to protect hard drive that is only used for backup?

« on: November 01, 2006, 07:31 PM »

As far as swapping, I'm going to use SATA drives, so I've learned that you can just hot swap them, which is cool!

-superboyac (November 01, 2006, 05:29 PM)

One thing to watch out for here is that some SATA controllers don't register drives being connected while the machine is running, for some bizarre reason. I don't think it's hugely common, but my new mobo, which has 3 different SATA controllers, recognises hot-connected drives on two of the controllers, but not on the third.

I expect you'll be fine, but you might want to check it works before splashing out on drives.

9

Living Room / Re: Mobo dying .... suggestions please on upgrading my system ...

« on: November 01, 2006, 07:21 PM »

Hi Carol,

There's quite a lot of stuff to consider there, but one thing jumped out at me: you have a RAID-0 setup using the onboard controller. It's pretty likely that, if you plug those drives into another RAID controller, you won't be able to access your files. Even with the same RAID controller chip, I don't think there's any guarantee that it will work.

If your mobo is dying and you don't already have a backup of the files on your RAID array, it's probably a very good idea to sort that out first. Once the mobo dies, your chances of getting at your files is pretty slim.

As far as the rest of the machine goes, I would say it's probably of an age where upgrading one or two core components isn't really worth it. You kinda need to use bits from the same era (if era is a valid way to describe something which happens every 6 months) or you risk wasting money on components which are starved by the older components. For example, it's probably not worth going dual core unless you plan on getting faster memory, since you'd now effectively have two CPUs trying to use the same memory bandwidth as before.

I guess the simplest, cheapest solution would be to just get a replacement mobo that will take all your hardware as-is (not including the RAID array). Although they are becoming fairly rare now, you can still get Socket A / AGP mobos, and they should be fairly cheap (around £30). Not a very exciting option, but there you have it. Oh, and Overclockers probably isn't the best place for less cutting-edge hardware. I can point you at a few other places that might have what you want if you decide to take this option.

Other than that, I'd be inclined to relegate the machine to PC#2 and build a new one. There are quite a few new mobos that will take your 4 IDE drives, although you need to be careful when choosing one. You're also unlikely to get an onboard IDE RAID facility on new mobos, but I'm not a fan of onboard RAID, so I'm not going to list that as a downside. That said, if you're building a new machine, you'll probably want to keep one or two of your current drives for PC#2 anyway, so you might end up wanting to get a shiny new SATA drive, which will reduce your need for lots of IDE ports.

If it was me though, I'd be worrying about that RAID array before anything else.

10

Find And Run Robot / Re: Chosen item number appearing in next search bug

« on: October 29, 2006, 08:30 AM »

It doesn't actually bother me that much, but I can see it being a showstopper for the "Must. Launch. Faster." aficionados. Don't get me wrong - I do like the speed at which FARR lets me launch stuff, but the thing that really makes it work for me is the sheer reduction in effort it provides.

11

Find And Run Robot / Chosen item number appearing in next search bug

« on: October 29, 2006, 06:47 AM »

Mouser,

This bug was mentioned recently, but I think I've got a 100% repeatable test case that you can try it on.

For me at least, if you use the numpad to invoke an item, the number you selected will show up as the initial search field the next time you bring FARR up, but only if the item is a URL. It seems to happen both with .URL files and with URLs in aliases. I don't seem to ever see it happen with anything else.

Hopefully this will give you a better idea where the problem might lie.

12

General Software Discussion / Re: Firefox 2 hints and tips

« on: October 27, 2006, 06:17 PM »

Ooh, I just noticed that the setting Carol mentioned was spelled extensions.checkCompatability, but it should be extensions.checkCompatibility. If you had to add it manually, maybe you've got the same misspelling in your prefs?

One way to check if it's working is to look at the Extensions Manager and you should see an info box telling you that you have compatibility checking disabled. You need to restart FF after changing the setting before this shows up though.

13

General Software Discussion / Re: Firefox 2 hints and tips

« on: October 27, 2006, 06:09 PM »

The Roboform installer checks which version of FF you are running and installs a different version of the extension for 2.0, so if you installed Roboform before upgrading, that would explain why it says it isn't compatible. Same thing happened to me, trying to get the latest version of everything before the FF update.

Installing Roboform again should fix it.

14

Post New Requests Here / Re: IDEA: Super Efficient Extended Hotkey Mapper

« on: October 26, 2006, 05:26 PM »

If you feel it's ahk's fault, post ait at the ahk forum. I'm sure they'll be able to provide a solution or if there is no solution, they'll solve it on the next release. At least, that's how it's happened with me

-jgpaiva (October 26, 2006, 03:57 AM)

I just tried a search there and found a solution, as well as a better way to do what I was trying to do.

It turns out that AHK provides useful built-in variables for the previous and current hotkey, as well as the time since the last hotkey. Using them, DoubleKey() turns into:

[Select]

DoubleKey(sendKeys, timeout)
{
  if(A_PriorHotKey = A_ThisHotKey and A_TimeSincePriorHotkey < timeout)
    Send, %sendKeys%
}

Pretty nifty. In fact, there's not really much benefit to my nice, neat function any more.

The problem with using separate left/right Ctrl/Alt/Shift can be solved by doing two things.

First, the "repeating key when held down" issue is strangely solved by making the hotkey respond to key-up events instead of key-down events - you can do this by putting " Up" in the hotkey name. This also seems to solve a problem I noticed when you make the timeout quite short (200ms or less), where the trigger sometimes wouldn't work - this seems to be related to which key you are using.

The other issue that was happening was that the LCtrl/RCtrl versions weren't allowing normal CTRL+key presses to get through to other apps. This is fixed by using the "~" modifier, which tells AHK to pass the hotkey to the underlying app rather than swallowing it completely. This shouldn't be necessary, since CTRL+key is a different key to CTRL on its own, and isn't for the non-left-right versions, but it seems to be necessary for the left-right variants.

So my hotkey for running FARR is now:

[Select]

~RCtrl Up:: DoubleKey("^!k", 200)

One other thing I noticed (while typing this actually), is that setting SHIFT as a double tap key can be slightly problematic depending on how fast you type. For me, quoted strings seem to involve a quick shift to make the " and then a quick shift to make the capital letter or symbol following it. It seems that I quite often do this sequence in less than 500ms, so I've got my timeout set at 200ms now. It's amazing the things you find out about yourself sometimes.

15

Post New Requests Here / Re: IDEA: Super Efficient Extended Hotkey Mapper

« on: October 25, 2006, 09:52 PM »

Although I can understand the desire to have a small, fast app to provide this functionality, it's fairly easy to do with AHK, and I don't find AHK that much of a system hog anyway. Using AHK also has the advantage that you can do plenty of other things besides sending alternative keystrokes, if you need to.

I've just added a simple double tap feature to my default AHK script (which runs at startup and provides most of my global hotkeys). One nice thing about this is that it's one less tray icon to worry about, and also minimises the overhead of running multiple hotkey processes.

The code for this is pretty simple. Near the top of my script, I have the following function:

[Select]

DoubleKey(key, timeout, sendKeys)
{
  global
 
  if(tapped%key% and (A_TickCount - tapTime%key% < timeout))
  {
    Send, %sendKeys%
    tapped%key% = 0
  }
  else
  {
    tapped%key% = 1
    tapTime%key% := A_TickCount
  }
}

And then to use it, I just create a hotkey which calls this function. For example, my FARR double tap hotkey is as follows:

[Select]

Ctrl:: DoubleKey("ctrl", 500, "^!k")

The "^!k" is the CTRL+ALT+K key sequence I use to bring up FARR normally, and the 500 is the time allowed between the two taps in milliseconds - if you wait any longer before pressing CTRL again, it resets and you have to tap twice again.

The "crtl" is used by the function to distinguish between different double tap keys. For example, if I also set up a hotkey for a double tap of SHIFT, it's probably better if the state of the double tap is kept separate from the state of any CTRL double tap, so the "ctrl" is used as part of the state variable names. The SHIFT hotkey would use "shift" (or anything else, so long as it's different from "ctrl"). If you don't do this, then SHIFT followed quickly by CTRL would fire the CTRL sequence, as if CTRL had been pressed twice.

Interestingly, it might be possible to make use of this kind of sequence, e.g. SHIFT then CTRL could fire a different sequence from CTRL-CTRL or SHIFT-SHIFT, as could CTRL-SHIFT. My current script can't do this, but it should be possible.

The only thing I haven't managed to solve yet is using the left and right SHIFT/CONTROL keys separately. If you use the LCtrl/RCtrl/LShift/RShift hotkeys in AHK, there seems to be some sort of repetition happening, which causes the sequence to fire any time you hold those particular keys down. I'll see if I can fix that when I have more time, but the current code seems to work very well for the Ctrl, Shift and Alt hotkeys.

16

General Software Discussion / Re: Windows Vista EULA to users: Go to hell!

« on: October 23, 2006, 05:47 PM »

NeilS, adopting software with a nasty EULA is like playing the backwards lottery. You are betting that you won't be the one to get the hammer dropped on you. But no matter how good the odds are, it's still a bet.

-Jimdoria (October 23, 2006, 03:24 PM)

Well, that's one way of looking at it. But if you assume worst case always, then you'd never cross the road, because you're betting that some idiot in a car won't hit you, no matter how good the odds are.

Anyway, it's nothing like a lottery, because a lottery is entirely random. The enforcement of the EULA is going to go one way or the other (in general - obviously there will be rare cases where someone get screwed or gets something for free), and it's going to depend on how MS decides to balance profits agains negative PR. If people really aren't sure how the EULA (or rather, how MS intends to enforce it) will affect their usage model, and if they can't afford to fall foul of it, then they'd be advised to wait and see how it affects people in a similar situation.

There's a slim chance that an outcry at this time will cause MS to change the EULA, but it's exactly that: slim. It's going to be pretty hard to get enough people shouting loudly about it when no-one has actually been screwed by it yet. However, if they do enforce the EULA to the letter, I expect we'll hear some fairly loud shouting sometime early next year.

17

Living Room / Re: MIT Smartboard video — MUST-SEE

« on: October 23, 2006, 02:26 PM »

Here's the reason why you thought it was apple's (it is ).

-jgpaiva (October 23, 2006, 10:14 AM)

I know Apple have done some work on multi-touch displays, but I didn't think that particular technology was anything to do with them. Mind you, they have patented a nice wall all round that area now, so it might as well be theirs. 

18

Living Room / Re: MIT Smartboard video — MUST-SEE

« on: October 23, 2006, 06:59 AM »

Combine that with the multi-input display stuff from apple(?)...

-f0dder (October 22, 2006, 10:58 AM)

You mean this? http://www.cs.nyu.edu/~jhan/ftirtouch/

Possibly the most awesome thing ever. I'm already saving up for one.

The only thing that could make it better is some kind of force feedback system so that you can feel controls and other elements in some useful way. Immersion used to have a force feedback mouse which did that kind of thing (e.g. becoming a bit "heavier" when you went over buttons), which was pretty cool, although also pretty limited in a lot of ways. No idea how they would achieve feedback on a screen though - maybe some sort of nanotech is in order?

19

General Software Discussion / Re: Windows Vista EULA to users: Go to hell!

« on: October 22, 2006, 11:21 AM »

Policies can change over the time. If more than occasionally pain in the butt even MS will have to adjust.

-dk70 (October 22, 2006, 09:03 AM)

I'm not even sure if this will be necessary. As nasty as the new EULA sounds, we don't have any way of knowing at this time if MS will enforce the "one move" rule to the letter, or if it's just a legal measure to give them more ability to say no in cases where they suspect foul play. If the previous EULA wasn't entirely clear about situations in which MS would say no, then I can imagine that MS had a few cases where they suspected foul play and their lawyers told them to back off a bit because the EULA might not stand up in court as well as they would have hoped.

So there is the potential that, with the new EULA, nothing will really change for the vast majority of people, even most enthusiasts. Of course, this assumes that the spirit behind the EULA is somewhat less draconian than the actual wording in it, which I suspect it will be. The problem MS face is convincing people of this, which they don't seem too bothered about just now, not that I'd expect it to do any good if they did try to reassure people.

20

General Software Discussion / Re: The Vista "kernel access" controversy - what does DC think?

« on: October 19, 2006, 07:34 PM »

Neil, I'd be a lot less suspicious of this from the A/V vendor side if there were more unanimous outcry about it, and if the firms I actually respect had a problem with it. But as is, like I said, it's mostly the firms I don't like and who I think make poor products anyway (that don't protect that well *as it is*) that are crying for this level of access. Frankly I don't want Mcafee or Symantic digging around in my kernel! The problem is you can't just allow access to only them, either. It has to be basically opened up for anyone with "the right credentials" to access. That seems like a huge and unnecessary hole to me.

-JavaJones (October 18, 2006, 09:03 PM)

Yes, I would agree that the companies making these claims don't fill me with confidence that the claims are entirely valid. Then again, just because I don't rate them as highly as Kaspersky or ESET, that doesn't mean that their claims are invalid either.

As for opening up the kernel for modifications, there's no reason why this should have to cause a hole. First off, the kernel can ask the user if he wants to allow a modification, much like a firewall will ask before authorising outbound traffic. If this isn't deemed secure enough (e.g. an attacking program might just click the "yes" button for you), then they could easily require that kernel mods are done during a reboot, where the user is asked in a much more controlled environment (i.e. only the kernel is running).

As for legitimate reasons, you speculate they have some, but I've not heard of any. I'm no expert, but from where I stand MS's arguments make at least as much sense as the A/V vendors - IMO a good deal more in fact. The only thing that gives me pause about it is MS caving so quickly, but I think the antitrust stuff, especially in the EU, is playing heavily into that, so the picture is not entirely clear without that taken into account.

-JavaJones (October 18, 2006, 09:03 PM)

I'm not entirely convinced that MS's arguments do make more sense. One of their main arguments seems to be that kernel patches can be unstable, and extrapolate from this that kernel patching in general is a bad thing. This is FUD, basically, and I would be more inclined to believe them if they stayed away from this line of argument.

Coming back to what I was saying above, MS also say that there is no way to tell if a kernel patch is coming from a legitimate program or a piece of malware. Of course you can tell - you limit kernel patching such that it can only occur in an environment where you can ask the user unambiguously if they want to allow the patch or not. They might argue that you can't trust the user to know whether to say yes or no, but if this were true, then the whole notion of outbound checking firewalls goes out the window, because they rely on the same kind of mechanism.

The other thing which is slightly concerning is how much of this is down to MS trying to lock down the DRM media route in the OS. If this is a large part of it (and some people seem to think it is), then this would also cause me to question the real agenda behind this stuff.

21

General Software Discussion / Re: The Vista "kernel access" controversy - what does DC think?

« on: October 18, 2006, 05:12 PM »

Locking people out of the kernel is a pretty low-level security measure to protect against a relatively few very specific attacks. Most viruses *do not* alter the kernel at present, and A/V providers shouldn't necessarily have to either. MS already said they would allow companies to replace their warnings and whatnot with their own version - that seems to be enough to satisfy the needs you outline (which I agree are very legitimate). All I can really say to that in closing is that from what I've seen 3rd party companies have historically always been responsible for *complicating* the security and protection scenarious, not simplifying them (albeit they do generally provide more protection than MS's defaults). So I'm not sure I really see your point. I agree that is basically what these companies are arguing, but I'm just not convinced at all that they need this level of access to provide their services adequately.

-JavaJones (October 18, 2006, 04:09 PM)

The fact that most viruses don't alter the kernel "at present" doesn't strike me as a useful security policy. When/if they do start doing this, how are the security vendors supposed to respond? Or should they just rely on MS to patch the hole sometime in the next month? What do they tell their customers in the meantime?

I also don't think the argument is just about AV protection. It sounds like some of the complete security suites have "legitimate" reasons for patching the kernel themselves, so that they can hook various things to provide extra forms of protection. OK, so maybe binary kernel patching isn't a great idea, and possibly even dangerous if achieved via false assumptions, but this just tells me that MS should be opening up the kernel for a more legit form of patching as well as locking it down against unauthorised modifications.

(Slight caveat to the above: I have no idea if any of the security vendors have actual legitimate reasons for needing to patch the kernel, so you could be right that none of them really need access. I'm pretty sure that legitimate reasons could exist, but that's not the same thing of course. )

22

General Software Discussion / Re: The Vista "kernel access" controversy - what does DC think?

« on: October 18, 2006, 04:00 PM »

There's obviously a certain amount of self-preservation going on here on the part of the various security vendors, but there's also more than an element of truth to what they are saying.

When it comes to security, choice is pretty critical. Part of this choice simply comes down to who you trust (and I'm sure plenty of people are understandably wary of trusting MS that much), and a large part of it comes down to how you want the security measures on your system to manifest themselves.

For example, the average Windows user isn't going to want their system so locked down that everything they do causes a security dialog to pop up. In fact, the average user won't know what many of the dialogs mean. So they typically want security which does a decent job with minimal user interaction.

More discerning/paranoid users might want increased security, and won't mind paying the extra cost in terms of effort required to train/tune the system to be as secure as possible.

By locking security vendors out of the kernel, MS would be effectively removing the user's choice of security system. Although MS could conceivably provide a security system which caters for most people pretty well, they'll never cover everyone and, to be honest, covering "most people" has never been their strong suit either.

Anyway, it sounds like they might be backtracking already, but even if they aren't, it's likely that they will at some point. It wouldn't be the first time.

23

Living Room / Re: MouserMon - a silly tool that lets you know when the Boss is/not on the foru

« on: October 18, 2006, 11:38 AM »

That might just be the best thing I've ever seen.*

*(I'm sure I said that about something last week, but this is probably better.)

24

General Software Discussion / Re: NOD32 update - does auto update work?

« on: October 17, 2006, 02:51 PM »

Yeah, not telling you on a manual update is a tad strange. Ah well, at least they seem to be getting the important stuff right, so I guess we can't complain too much. <touch wood>

25

General Software Discussion / Re: NOD32 update - does auto update work?

« on: October 17, 2006, 12:41 PM »

I was on 2.50.something until fairly recently, and didn't notice much change when I updated to 2.51.26, so it does seem as if they don't bother you with the program update unless you really need it. (That's not to say that there isn't an important difference under the hood, but the website only has a warning to pre-2.5 users to get 2.5, so 2.51 doesn't seem particularly critical).

I think I prefer this, to be honest. McAfee was forever wanting a reboot after a program update, and I'll bet you most of those updates were completely pointless.