|
Only if the software is buggy and can't read back what it wrote itself. TC/VC are so mature at this point, I really don't worry about that.
If you're thinking about disk failures...then (a) that's why I do my backups in pairs and (b) an unreadable sector is simply unreadable, whether it's encrypted or not. And things like SpinRite don't care whether a sector is encrypted or not - these tools only concern themselves with trying to recover raw bits. They don't even know whether they're reading a FAT partition, NTFS, ReFS, ZFS, whatever.
|
|
|
|
|
I use SyncBack (free). It allows a number of different options, so that you copy one way or do a sync. It also allows you to do a simulated run and logs what will change.
Just curious, why have you encrypted the whole disk? Doesn't that make access a whole slower?
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
yacCarsten wrote: I use SyncBack (free).
I'm not sure how this helps here TBH. I'm talking about migrating from one encryption system (TrueCrypt) to its successor (VeraCrypt).
yacCarsten wrote: why have you encrypted the whole disk?
As per the top of my post...I don't want to take the time to selectively decide what needs to be encrypted (eg, my banking info), vs what's fine to remain unencrypted (eg, setup programs, which just happen to exist on the same disk). Just encrypt the whole thing and be done with it.
yacCarsten wrote: Doesn't that make access a whole slower?
Possibly. Could I actually measure it, especially nowadays? Maybe if I was transferring the entire content of the drive - which only happens in extremely rare circumstances like this one, which is pretty much a one-time operation. Besides, they're backup drives - they're only being used when I'm updating my backups or when I find out I need to recover a few very specific files (which has happened maybe...3 times since I've started maintaining backups decades ago?)
|
|
|
|
|
Every morning I open Code Project and start with the news.
Every morning I find a new application or framework or both.
My question is how many of those, are actually used by developers, other than the people who created them?
I believe that some of those created last year are still in use today, but not many.
Really! I don't intend to criticize those that developed them; however, the learning curves have got to be tremendous.
Am I a hopeless luddite?
What do you think?
|
|
|
|
|
|
That there are too many frameworks? Or that he is a hopeless Luddite?
You could always embrace the power of โandโ!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
The same as him. 
|
|
|
|
|
A framework really helps if it's intended for your domain and has a low surface-to-volume ratio. Without one, the outcome is superfluous diversity, which makes it hard for software to interoperate without writing glue that would otherwise be unnecessary.
Ideally, a framework should be developed internally so that it can evolve to suit the needs of your applications. But if an external framework is a good fit, and if it's responsive to its users, it's worth considering.
The worst outcome is a team without a framework. It can happen because management thinks everyone should be developing features or because no developer has enough domain experience to develop a framework.
|
|
|
|
|
When I read about software code having a "low surface to volume ratio", I know I have stumbled into Pseuds Corner. ๐โน๏ธ
|
|
|
|
|
What does that even mean: "low surface to volume ratio"???
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Good question! It's just techno-babble as far as I can make out.
|
|
|
|
|
I understand that the lowest surface area to volume ratio is possessed by a ball, so maybe such code is balls?
|
|
|
|
|
Absolutely.
The first thing we do after defining the problem/solution space and what the project IS NOT.
Is too look at what type of Framework is needed.
Both for web and thick clients, etc.
How will we all talk to the DB
How will we wrap/protect the database (a lot of system views).
The framework gives us handrails for adding functionality. Allows us to prototype quicker.
And get user feedback quicker.
The Flexibility of using views includes the ability to add columns in real-time, and have them show up in various grids/pages...
And I would NEVER want to use the same framework every project. Ever! LOL
|
|
|
|
|
Ditto
PartsBin an Electronics Part Organizer - A updated version available!
JaxCoder.com
|
|
|
|
|
We're both hopeless luddites when it comes to the Framework du jour. The fundamental problem with frameworks is that as soon as your requirements go outside the framework you start fighting the framework. Since no two projects are the same this means that frameworks invariably cause more technical debt that has to be dealt with down the road.
|
|
|
|
|
That can be true, but there will usually be more technical debt without a framework.
|
|
|
|
|
I consider trying to shoehorn a framework into your needs to be the largest technical debt you can incur.
|
|
|
|
|
Yes, agreed.
Each framework solves one maybe two valuable problems. You know it's going to suck when the people making the call ignore all that and just pick the popular new shiny thing, so people will like them more.
Sure guys, let's do a single page app in a jazzy .ts framework.. only to chew it up and spit it out as thousands of different pages served as static files with no binding whatsoever. Great job guys, you sure captured the design philosophy of that framework! Odd thing that all our frontend devs are now running away, though. Very odd that.
|
|
|
|
|
I've worked on a varied bunch of projects using the Django web framework, and the only times I've felt like I'm fighting the framework is when a lesser programmer has written idiotic code because they thought they knew better than the framework in the first place, and I'm the chump stuck maintaining it.
There are good frameworks that work for a wide variety of things, but you must drink the kool-aid. You have to do it their way through and through, and only then do you get the benefits of a framework.
|
|
|
|
|
Maybe I'm reading this wrong, but it sounds to me like you're saying you're overwhelmed by all the frameworks that are out there, with new ones being published daily.
You don't need to know every framework that's out there. Or even know about those frameworks.
When I started my career as a Windows developer, I thought I'd become a kick-ass developer if I just learned every API there is in Windows. It didn't take long for me to conclude that's just not realistic. And that's just one company.
Read about what you find interesting or is relevant to your job, and ignore the other 99% of the stuff that gets published daily. Most of it is bound not to lead anywhere over time anyway (or at least, not anywhere that should matter to you).
Or am I misunderstanding your question?
|
|
|
|
|
Pretty sure you're misunderstanding it - the way I read it, he's saying there appear to be a lot of low uptake languages and frameworks with no reason to have been written in the first place outside of a hobby project for a bored programmer, and no reason to enter his eyeballs outside of show&tell. His question is then whether he's mistaken.
|
|
|
|
|
shrug
Could be. But why should anyone have concerns about anyone's pet project that only the author uses?
|
|
|
|
|
|
Spammers don't spend that sort of time on their pet projects.
|
|
|
|
|
You misunderstand.
irrelevant or unsolicited messages sent over the internet, typically to a large number of users, for the purposes of advertising, phishing, spreading malware, etc.
Definition courtesy Bing.
Spammers are by definition those who create spam, which is irrelevant or unsolicited messages sent over the internet. It doesn't have to be for monetary gain, even though that's the usual purpose of spam. A ten year old spamming "fart" in IRC is just as much a spammer as a thirty-six year old spamming Pfizer advertisements to your inbox.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
