The FBI explicitly investigated whether there was an attempt to hide emails. Here is Comey's statment:
> The lawyers doing the sorting for Secretary Clinton in 2014 did not individually read the content of all of her e-mails, as we did for those available to us; instead, they relied on header information and used search terms to try to find all work-related e-mails among the reportedly more than 60,000 total e-mails remaining on Secretary Clinton’s personal system in 2014. It is highly likely their search terms missed some work-related e-mails, and that we later found them, for example, in the mailboxes of other officials or in the slack space of a server.
> It is also likely that there are other work-related e-mails that they did not produce to State and that we did not find elsewhere, and that are now gone because they deleted all e-mails they did not return to State, and the lawyers cleaned their devices in such a way as to preclude complete forensic recovery.
> We have conducted interviews and done technical examination to attempt to understand how that sorting was done by her attorneys. Although we do not have complete visibility because we are not able to fully reconstruct the electronic record of that sorting, we believe our investigation has been sufficient to give us reasonable confidence there was no intentional misconduct in connection with that sorting effort.
Quassel is awesome, and has a really interesting idea in wanting to store logs in an sqlite db for better searching, but ironically in the current client implementation this seems to make it harder to search for stuff.
While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Once better long term search has been implemented in the client, quassel will become the best GUI IRC client hands down, I look forward to seeing the progress made in this area.
If I remember correctly, it has massive SQL-injection holes and isn't maintained anymore. The issues are known (quassels website etc warn people against using quasselsuche).
> While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Why not just open the sqlite file and search in there? Could even ask for the log to be stored in an FTS table for fast FTS queries.
That may work, but then you're in the same workflow as the more traditional IRC clients with their .txt logfiles and needing tools external to the IRC client. Ostensibly the point of moving away from the human-readable logfiles to something like an SQL DB was to let the client be a more powerful search engine into your chat history. So this is mostly a lament that while there's a great vision to what an IRC client can be in designing Quassel's infrastructure, Quassel has not yet fully realized its vision in this area, but I'm sure it'll get there some day.
I think the OP's original complaint is bore out of the idea that: if the client is already storing the logs in a structured format with a schema to accompany it, and the data engine has query features for that data which is powerful like grep (as SQL does), and it's already using that engine to power search for the immediate buffer - it seems a bit odd then to not build 'global' search right into the application, for all logs, based on the same mechanism.
I think it's nice you can do all the SQL dumping/munging stuff, given the implementation. I just don't want that in 99% of all use cases - the application doing search itself is enough normally. It's not like I use any of grep's more powerful features when I search logs, 99% of the time it's just something like "| grep foo" and I narrow it down iteratively or just pick out the result.
Honestly, technical specifics aside, this is also a matter of usability, and is something Slack gets very right: you never have to do anything for search to work well for the vast majority of use cases, even for very long histories. You just type the words you want and the results always come back, even from weeks or months before. Telling users to enable logs and then search text files is just much more activation energy. Telling them to do that after exporting their data from SQLite, even more so.
I'm using it with postgres, and yeah I don't know why there's no option to search all historical logs (well I guess if I really wanted it, it is an open source project), but since I have desktop client opened all the time, in settings I have it configured to fetch some ridiculous amount of backlog, and then ctrl-f searches quite far in the past.
As someone who grew up in the 90s where GIFs became popular for their use in looping animations, I don't understand why these files became popular for this kind of use case of step-wise instructional material (or even worse, as general-purpose video containers). Sure they may be more lightweight than videos, but isn't it frustrating to miss a step and have to wait for the entire GIF to loop all over again? This can happen especially with tutorials that use GIFs sprinkled throughout. By the time you scroll to them you end up halfway through the animation or aren't sure what step you're at and how long you need to wait for the repeat.
Maybe this is more of a browser-issue and if we're going to embrace abusing GIFs as video containers perhaps browser vendors should give the user video player-style controls?
At least one image hosting site[1] is going in the opposite direction, converting GIFs to H.264 videos to save bandwidth and CPU time. They don't show playback controls - although (in Chrome, at least) you can right-click and enable controls.
Now that vim is on github, I think it'd be cool if eventually the vim logic/model could be abstracted into a library that could then be used by any text editor to instantly provide the basic vim experience without all the edge cases that current reproductions tend to have.
It'd be cool to see native vim commands for browsing / email clients etc, not sure of the point behind adding it to a text editor. Seems like a good way to lose users to the real thing in a slow hurry.
You're right. It looks like they're not using the onboard ethernet controllers for whatever reason, and instead dangling ethernet off of USB. So now I'm grumbly about that because the onboard ethernet is much more powerful.
If I understand correctly, the DRM system consists of a special ink on the lid of the cup. Therefore, some people have figured out that you can simply cut off that piece and tape it to the detector so that it will always think you have an official cup inside.
https://wikileaks.org/podesta-emails/emailid/9272#efmBA7BOJ