Skip to content

Instantly share code, notes, and snippets.

View Micrified's full-sized avatar
🇫🇷
Collating...

Micrified

🇫🇷
Collating...
  • Rotterdam, Nederlands
View GitHub Profile
abscissa
alluvial
animist
arrogated
atavistically
balusters
bivouac
blue sky
burnooses
carboy
3 (Number of Nodes)
3 (Number of local nodes)
3 (Number of edges)
3 (Number of starting nodes)
0 1 2 (All IDS of local nodes)
0 1 1 (Edge 1: <start end weight>, so from 0 to 1 with weight 1)
0 2 3 (Edge 2)
1 2 2 (Edge 3)
rmi://localhost:1099/node-0 (URL 1)
rmi://localhost:1099/node-1 (URL 2)
@Micrified
Micrified / gist:16e97123a16674c925791b95b3033ac5
Created December 20, 2018 13:13
Example 4 Input (ChangeRoot)
4
4
4
4
0 1 2 3
0 1 1
1 2 3
2 3 2
3 0 4
rmi://localhost:1099/node-0
java -Djava.security.policy=my.policy -Djava.rmi.server.hostname="$1" ghs_election/GHS_Election ../../$2
@Micrified
Micrified / txt
Created January 13, 2019 20:18
Summary
The Application Customizable Branch Predictor (ACBP) is a design proposed by Raid Ayoub and Alex Orailoglu that attempts to exploit the relationships between remotely correlated branches in global branch history. Although Ayoub and Oraioglu acknowledge that there are stronger relationships between locally related branches, they maintain that remote correlations are still useful and worth predicting. Their design intends to both save power and improve accuracy by filtering out branching history that is unnecessary to store. This allows the branch predictor to be smaller, and thus more power efficient. By only filtering unnecessary branching history, Ayoub and Oraioglu ensure that no accuracy will be lost. In fact, the performance is improved over that of traditional predictors due to the information gained from remote correlations.
The architecture of ACBP preserves important global branch history by storing it in a dedicated section of the predictors global-history-register (GHR). As branch predictions are
// Returns the first-set for the given non-terminal.
func firstSet (b byte, g I) ([]byte, error) {
var set []byte = []byte{};
var hasEpsilon bool = false;
// Ensure b is a non-terminal.
if !isNT(b) {
return nil, errors.New("First-Set only valid for non-terminals!");
}

This concerns incorrect or faulty installation instructions for both Ubuntu and Fedora.

Fedora

OS: Fedora 29

The installation instruction:

$ sudo dnf install dnf-utils
$ sed 's/%{npm-version:.*}/0/' tools/cockpit.spec | sudo dnf builddep --spec /dev/stdin
@Micrified
Micrified / gist:00aa24d8bc607a025e13425cbf765b83
Created March 12, 2019 06:30
Interesting excerp from Cockpit source code
static gboolean
validate_path (const gchar *name)
{
static const gchar *allowed = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.,/";
gsize len = strspn (name, allowed);
return len && name[len] == '\0';
}
@Micrified
Micrified / Internal_Structure_Report.md
Created March 12, 2019 12:46
The Internal Structure of the Project

Cockpit Project Structure

The Source Directory

The Cockpit project's src directory contains a series of modules organizing the source code for the webserver, authentication services, data-parsing routines, and internal communication protocols. The subdirectories are listed below with their respective contents. Finally, most of the directories contained within the project contain testing files prefixed with "test", auxillary testing files suffixed with "samples", or "mock" files. A smattering of other kinds of make files and configuration files are also present. In the interest of documenting the functionality most central to the project, I've chosen to elide those from the summary below.

  • common: Common contains the core functionality of the project, namely the webserver and internal message passing facilities. The following files contain the most important components of the source code. All files listed here are written in C
  • cockpitwebserver: The webserver source code (request handlers
@Micrified
Micrified / ns_notes.md
Created March 18, 2019 14:54
Notes on Network Security Lecture

IP Fragmentation and Reassembly.

  • Adversary can flip fields or fragments in an IP packet.
  • Premature assembly (look at packets coming in, one signals the last packet. If you miss some packets, then you wait to receive it. If message is received which says you have everything, you try (and keep trying) to reassemble. Form of DOS.
  • Message indicates you must wait for data. Then more data comes than you can store or reassemble (DOS).
  • Fragmentation Border Cases
  • IP packet max length 2^16. Fragmentation offset is 2^13.
  • You only realize you are out of memory when the specified packet size turns out to be smaller than what is actually transmitted.
  • Suggests a buffer overflow then occurs, seems like that only applies to shit code practices.
  • Ping of death
  • Spam prevention avoids spoofed IP addresses by checking if sending IP is one actually associated with organization (?)